On Fri, Jan 8, 2010 at 8:35 PM, Bret McMillan <bretm@xxxxxxxxxx> wrote: > On 01/08/2010 01:59 PM, Mike McGrath wrote: >> >> On Fri, 8 Jan 2010, Matt Domsch wrote: >> >>> On Fri, Jan 08, 2010 at 11:07:53AM -0600, Mike McGrath wrote: >>>> >>>> On Fri, 8 Jan 2010, Bert Desmet wrote: >>>> >>>>> Hi >>>>> >>>>> mmcgrath asked me to collect some statistics about the fedora website. >>>>> He asked me to use yahoo's yslow. >>>>> You can find the results here: http://bdesmet.be/upload/finished.pdf >>>>> yahoo's page with extra information on every test: >>>>> http://developer.yahoo.com/performance/rules.html >>>>> >>>> >>>> Thanks bert. I'm wondering how much of these we can do something about >>>> (the low hanging fruit) >>> >>> The "Use a CDN" messages all disappear with a config file setting >>> stating that fp.o _is_ a CDN. >>> >>> Setting up better expiry times on /static/ and /web/static/ should be >>> low-hanging fruit. >>> >>> Adding compression should be low-hanging fruit, but will increase the >>> CPU needed on the app/proxy servers. >>> >> >> I've wondered about this, we should get some metrics. I've tested >> compression between the browser and the proxy servers and the good news is >> the proxy servers didn't seem to notice. The question I'd have is if >> compression between app servers and the proxy servers would help. > > Unlikely (it might even slow stuff down, depending). +1 to enabling it a > the proxy layer, and leaving the rest alone. > >>> CSS at top, and javascript at the bottom, I can't say, having not >>> looked at the pages in question. May be easy. >>> >> >> Is this just bad practice or does it actually cause some issue? > > Doing things this way tends to allow browsers to do progressive rendering, > speeding up the perceived rendering speed of the page. Generally speaking, > going to get bigger gains from: > > * implementing CDN where applicable > * minimizing overall # of needed http requests > * proper caching semantics (including damnable etags) > * gzip compression > > If you knock out all of those, then maybe look at CSS & jscript optimization > as a next tier of effort. > > > Google has also produced a pretty neat tool called Speed Tracer: > > http://code.google.com/webtoolkit/speedtracer/ > > Might be worth poking around w/ that too. > > > --Bret > > _______________________________________________ > Fedora-infrastructure-list mailing list > Fedora-infrastructure-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list > If you compress on the app servers, there will be no increase load on the reverseproxies. And if you have a good hitratio on the proxies, the load will probably be insignificant on the appservers as well. Id also drop etags alltogether if you dont need them. I can also recomend http://www.webpagetest.org/ as an alternative to speedtracer and yslow. Cheers Stein Ove _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
