|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
CongratulationsThe Seam website just had its busiest month ever :-)
-- Gavin King gavin.king@... http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Congratulations That's great news, however, I want to bring up a related concern - the forums (and, to a lesser extent, the rest of the seam site) are very slow. Pages routinely take 2-5 seconds to load, which doesn't bode well for the perception of the framework. I have heard comments like "why is the site so slow? and it's written in seam?" (and myself said similar things when I was first introduced to Seam)
From looking at the code on the site from the examples/wiki directory, it looks like at least many sql queries seem to be optimized -- what else could it be? I have explored around the code but without a good dataset that represents live data, can't do much more. Is there a way to get a recent data dump of the website DB (with all usernames/passwords/other user data further hashed/obfuscated, of course).
If this is possible, some of us could take a stab at perhaps making the forums faster. It'll only help with adoption/use of the forums. Ashish Tonse
@atonse On Sun, May 31, 2009 at 2:00 PM, Gavin King <gavin.king@...> wrote: The Seam website just had its busiest month ever :-) _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: CongratulationsChristian says he thinks that the problems are:
(1) the wikitext parser is slow (2) it runs on a slow server in Europe On Mon, Jun 1, 2009 at 6:06 AM, Ashish Tonse <ashish.tonse@...> wrote: > That's great news, however, I want to bring up a related concern - the > forums (and, to a lesser extent, the rest of the seam site) are very slow. > Pages routinely take 2-5 seconds to load, which doesn't bode well for the > perception of the framework. I have heard comments like "why is the site so > slow? and it's written in seam?" (and myself said similar things when I was > first introduced to Seam) > From looking at the code on the site from the examples/wiki directory, it > looks like at least many sql queries seem to be optimized -- what else could > it be? I have explored around the code but without a good dataset that > represents live data, can't do much more. Is there a way to get a recent > data dump of the website DB (with all usernames/passwords/other user data > further hashed/obfuscated, of course). > If this is possible, some of us could take a stab at perhaps making the > forums faster. It'll only help with adoption/use of the forums. > Ashish Tonse > http://ashish.tonse.com > @atonse > On Sun, May 31, 2009 at 2:00 PM, Gavin King <gavin.king@...> wrote: >> >> The Seam website just had its busiest month ever :-) >> >> -- >> Gavin King >> gavin.king@... >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> _______________________________________________ >> seam-dev mailing list >> seam-dev@... >> https://lists.jboss.org/mailman/listinfo/seam-dev > > -- Gavin King gavin.king@... http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Seam website optimizationsOn 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@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: CongratulationsI find it to be quite slow as well. Although, I've experienced great success with Seam, it makes it harder to sell Seam to my peers because their first experience with the framework is that the web site which Seam is running on (seamframework.org) is slow.
I'm sure it won't surprise you that the web application we did use Seam with was not slow at all. It performed very well. - steve roy
On Mon, Jun 1, 2009 at 12:17 PM, Gavin King <gavin.king@...> wrote: Christian says he thinks that the problems are: _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsHi 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@...>: > > 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@... > https://lists.jboss.org/mailman/listinfo/seam-dev > seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizations> 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. I know the my stats are not helpful but out of interest, I'm 12 hops away and have ~100ms ping times but I still manage to spend ~4-5 seconds to load a thread with 4-5 replies --- Nik _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsOn Jun 01, 2009, at 19:51 , Sanne Grinovero wrote: > right about the load and optimized code, but if I run the "YSlow" I actually first had a paragraph in my e-mail saying "Please, no Yahoo website tips". :) I'm aware of all of this stuff and of course we've done already whatever makes sense and was easily doable. The website does NOT have many resources that are loaded with a warm cache. In fact, only the SeamResourceServlet files are loaded over and over again (remote.js particularly bad). Which is why we need conditional GET function for it. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsOn Jun 01, 2009, at 21:26 , Nicklas Karlsson wrote: > I know the my stats are not helpful but out of interest, I'm 12 hops > away and have ~100ms ping times but I still manage to > spend ~4-5 seconds to load a thread with 4-5 replies 1. That's not a good RTT if you have anything better than an analog modem, it should be more like 25 ms. 2. RTT is not throughput. 3. We know. ;) _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: CongratulationsI found that the site runs ok (although I'm in the UK).
I would make the suggestion that the forums are completely sorted as at the moment they are not great... Namely searching is not very good (especially if you are searching for phrases), jboss themselves seem to have quite a good looking forum module for jboss portal? I think a mailing list for seam users may be a good option as well, sometimes it's just easier to send an email off to a user group mailing list and get an answer quickly. On 1 Jun 2009, at 17:17, Gavin King wrote: > Christian says he thinks that the problems are: > > (1) the wikitext parser is slow > (2) it runs on a slow server in Europe > > On Mon, Jun 1, 2009 at 6:06 AM, Ashish Tonse > <ashish.tonse@...> wrote: >> That's great news, however, I want to bring up a related concern >> - the >> forums (and, to a lesser extent, the rest of the seam site) are >> very slow. >> Pages routinely take 2-5 seconds to load, which doesn't bode well >> for the >> perception of the framework. I have heard comments like "why is the >> site so >> slow? and it's written in seam?" (and myself said similar things >> when I was >> first introduced to Seam) >> From looking at the code on the site from the examples/wiki >> directory, it >> looks like at least many sql queries seem to be optimized -- what >> else could >> it be? I have explored around the code but without a good dataset >> that >> represents live data, can't do much more. Is there a way to get a >> recent >> data dump of the website DB (with all usernames/passwords/other >> user data >> further hashed/obfuscated, of course). >> If this is possible, some of us could take a stab at perhaps >> making the >> forums faster. It'll only help with adoption/use of the forums. >> Ashish Tonse >> http://ashish.tonse.com >> @atonse >> On Sun, May 31, 2009 at 2:00 PM, Gavin King <gavin.king@...> >> wrote: >>> >>> The Seam website just had its busiest month ever :-) >>> >>> -- >>> Gavin King >>> gavin.king@... >>> http://in.relation.to/Bloggers/Gavin >>> http://hibernate.org >>> http://seamframework.org >>> _______________________________________________ >>> seam-dev mailing list >>> seam-dev@... >>> https://lists.jboss.org/mailman/listinfo/seam-dev >> >> > > > > -- > Gavin King > gavin.king@... > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ > seam-dev mailing list > seam-dev@... > https://lists.jboss.org/mailman/listinfo/seam-dev _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsOn Mon, Jun 1, 2009 at 4:03 PM, Christian Bauer <christian.bauer@...> wrote:
I have no doubt you have put significant effort into understanding the performance of the website. But there is a new development in the area of performance. Google recently released the Page Speed plugin for Firebug, which I think it's worth pointing at the site to see if there are any new optimizations we can discover. Also, it appears that RichFaces is very guilty in terms of missing the cache and should certainly be discussed at the upcoming meeting in Brno. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsOn Jun 10, 2009, at 00:24 , Dan Allen wrote: > I have no doubt you have put significant effort into understanding > the performance of the website. But there is a new development in > the area of performance. Google recently released the Page Speed > plugin for Firebug, which I think it's worth pointing at the site to > see if there are any new optimizations we can discover. Also, it > appears that RichFaces is very guilty in terms of missing the cache > and should certainly be discussed at the upcoming meeting in Brno. We are way beyond running tools to find problems, we know what the (fixable) issues are: Richfaces is bad with a cold browser cache as it's delivering its JS and CSS content in dozens of requests instead of bundling the data in a few requests. This is obviously going to be on the table. However, with a warm browser cache it does conditional GET and cache control headers just fine and data is not downloaded again. Simplified: Yes, you can optimize the first visit to a page but any subsequent visit is not executing any requests and using the cached JS and CSS. The only thing that needs to be done is bundling up the resources better. As we are not using Richfaces components on sfwk.org on regular pages, this doesn't affect the website much. The Seam resource servlet does not do conditional GET and cache control headers. That is bad for people using @WebRemote, as this JS is downloaded on every page request, over and over. Also, an application like the wiki that uses the Seam resource servlet extensively for delivering plugin CSS/JS/IMGs is suffering from that. I've mentioned this before on this thread and there is a JIRA issue. If someone wants to work on it, contact me so we can coordinate. This has implications for REST integration as well. (Yes, Page Speed is great because it analyses some very obscure possible improvements. However, none of them would have any real impact compared to the two issues above.) _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizations
Okay, for all of you out there who really want to see an improvement in sfwk.org (and Seam in general), here is your chance to take action. If no one has time to get to it, I might dedicate time to this issue in the near future. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
|
|
Re: Seam website optimizationsRichfaces is bad with a cold browser cache as it's delivering its JS and CSS content in dozens of requests instead of bundling the data in a few requests. This is obviously going to be on the table. However, with a warm browser cache it does conditional GET and cache control headers just fine and data is not downloaded again. Simplified: Yes, you can optimize the first visit to a page but any subsequent visit is not executing any requests and using the cached JS and CSS. The only thing that needs to be done is bundling up the resources better. As we are not using Richfaces components on sfwk.org on regular pages, this doesn't affect the website much. Initial request performance is important too and is an area the RichFaces team is going to investigate for 4.0. How to bundle not only the static resources, but also the dynamic resources into as few requests as possible.
I think that page speed is good at visualizing offenders and pointing the way, but it is like a bird dog. It shows you where the meal is, but does not get it on the plate ;-)
-- blog: http://in.relation.to/Bloggers/Jay _______________________________________________ seam-dev mailing list seam-dev@... https://lists.jboss.org/mailman/listinfo/seam-dev |
| Free embeddable forum powered by Nabble | Forum Help |