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(a)redhat.com
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