[seam-dev] Seam website optimizations

[Christian Bauer]

On Jun 01, 2009, at 18:17 , Gavin King wrote:

> (1) the wikitext parser is slow

Which is why a forum thread with 50 replies takes a while to render.  
It's not detectable on a page with just a few comments/replies. We are  
caching what can be cached. Maybe that can be optimized further but  
I'm 95% sure it can't be done without major changes. As extremely long  
discussion threads are somewhat rare this is not a primary concern  
right now.

> (2) it runs on a slow server in Europe

The machine is fast but the connection to !EU countries is probably  
not great. There is not much load on the server. Regular pages all  
render in less than 2 seconds from warm browser cache - I don't care  
about cold cache. For simple pages with just plain wiki text I'm  
seeing around 600ms. Keep in mind that I have a good connection to the  
server's location. If you are not in central EU you probably won't. No  
need to post numbers, we know it's a problem.

There are three things that can be done and that would have a  
measurable benefit:

- Move the service to US so it's slow for EU instead, already work in  
progress.

- Conditional GET for SeamResourceServlet stuff, there is a JIRA issue  
about it. With this change we could get a plain basic page down to  
400ms from 600ms.

- Further optimize the forum list overview SQL query which is the only  
really slow query. Result is in fragment cache though, it's only  
executed when a new forum posting is made. This is an interesting  
nested join problem and if you really know the MySQL or PostgreSQL  
optimizer, have a go at it.

I need to repeat: The site itself, unless you run into a not-cached  
result on the forum overview every 10 minutes, is not slow at all. For  
most of you it's a connection/hops issue.

The conditional GET for SeamResourceServlet however is something that  
we should implement anyway as it affects all Seam projects. So if  
anyone wants to look at that, feel free and try it on the wiki code  
base.


(P.S. Yes, even 400ms for a simple page is too much. It's not Seam's  
fault. The code executes quite a few SQL statements for a simple page  
view. Why it does that is complex, it's related to the nested set data  
schema and the required entity inheritance model. It has already been  
optimized quite a bit. Unfortunately not much of the power that comes  
with the nested set strategy has been used so far and I probably  
wouldn't combine Java inheritance + ORM + nested set in a future  
project. Changing that now would mean rewriting large amounts of code,  
migrating the data, or even switching to a non-OSS DMBS with a working  
explode() operator. None of these options are attractive. OTOH, if you  
have the time...)