12:51 p.m.
Hi Christian,
I'm in Europe and the website is perceived slow, I am sure you're
right about the load and optimized code, but if I run the "YSlow"
firefox plugin it gives lots of good tips
you could apply to make it faster.
The website is behaving as "slow" because of the many resources which
are loaded per page; most browsers won't open more than 2 http
connections so all resources
are loaded in sequence: one bu one thorough all the hops; Using the
plugin I can see that many resources are not properly cached by the
browser because of wrong headers.
Other tips YSlow is giving are about missing compression on
javascripts, javascripts which could be moved to the bottom,moving
static rerources to "cookie-less" subdomains.
I'd recommend you to give it a try, I used it to speedup several Seam
applications: the most notable improvement is usually to fix the
headers from the richfaces generated javascript
when you can be sure it's not going to change, that will reduce the
amount of network roundtrips and the page will feel as loader much
faster.
Sanne
2009/6/1 Christian Bauer <christian.bauer(a)gmail.com>:
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...)
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev