FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Infrastructure

 
 
LinkBack Thread Tools
 
Old 01-07-2010, 10:56 PM
Bert Desmet
 
Default yslow website stats

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

cheers,
Bert Desmet


_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 04:07 PM
Mike McGrath
 
Default yslow website stats

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)

-Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 05:10 PM
Matt Domsch
 
Default yslow website stats

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.

CSS at top, and javascript at the bottom, I can't say, having not
looked at the pages in question. May be easy.

Rest are opportunistic I'd say.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 05:42 PM
Darren VanBuren
 
Default yslow website stats

The "Use a CDN" doesn't at all apply to our case. With the plentiful
spread of proxy boxes, (which serve static content) we're a small-
scale CDN by ourselves.


On the matter of Expires, here's what would need to be added to an
Apache config, assuming static stuff is in /srv/web/static:


<Directory /srv/web/static>
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType text/css "access plus 1 month"
ExpiresByType text/javascript "access plus 1 month"
</Directory>

Of course we can tweak the times, I just made up 1 month.

As for compression, yes it will increase load, but it will save users'
bandwidth and will increase speeds on slow connections (56K, EDGE,
EVDO). The compressed versions can be cached on disk as well so the
load of compression doesn't matter on read-only traffic.


Moving JavaScript to the bottom of a page is also a low-hanging fruit.
The thought is that presentation can be achieved, so users see the
page even though the JavaScript isn't loaded.


Darren VanBuren
==============
http://theoks.net/

Sent from my iPod

On Jan 8, 2010, at 10:10, Matt Domsch <Matt_Domsch@dell.com> 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.

CSS at top, and javascript at the bottom, I can't say, having not
looked at the pages in question. May be easy.

Rest are opportunistic I'd say.

--
Matt Domsch
Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list


_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 05:59 PM
Mike McGrath
 
Default yslow website stats

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.

> 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?

-Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 06:35 PM
Bret McMillan
 
Default yslow website stats

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@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-08-2010, 06:59 PM
Stein Ove Rosseland
 
Default yslow website stats

On Fri, Jan 8, 2010 at 8:35 PM, Bret McMillan <bretm@redhat.com> 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@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 http://www.webpagetest.org/ as an alternative to
speedtracer and yslow.

Cheers
Stein Ove

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-09-2010, 12:13 AM
Toshio Kuratomi
 
Default yslow website stats

On Fri, Jan 08, 2010 at 10:42:35AM -0800, Darren VanBuren wrote:
> On the matter of Expires, here's what would need to be added to an
> Apache config, assuming static stuff is in /srv/web/static:
>
> <Directory /srv/web/static>
> ExpiresByType image/gif "access plus 1 month"
> ExpiresByType image/png "access plus 1 month"
> ExpiresByType text/css "access plus 1 month"
> ExpiresByType text/javascript "access plus 1 month"
> </Directory>
>
> Of course we can tweak the times, I just made up 1 month.
>
Is this how Expires work? ::

* Client requests fp.o/static/fedora.css
* Client receives fedora.css with an Expires line of 1 month
* For the next month, the client does not retrieve new versions of
fedora.css.

If so, we're either going to want to keep the Expires time pretty low (an
hour or less) or start adding version information into all of our static
resources.

-Toshio
_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-09-2010, 01:04 AM
Mike McGrath
 
Default yslow website stats

On Fri, 8 Jan 2010, Toshio Kuratomi wrote:

> On Fri, Jan 08, 2010 at 10:42:35AM -0800, Darren VanBuren wrote:
> > On the matter of Expires, here's what would need to be added to an
> > Apache config, assuming static stuff is in /srv/web/static:
> >
> > <Directory /srv/web/static>
> > ExpiresByType image/gif "access plus 1 month"
> > ExpiresByType image/png "access plus 1 month"
> > ExpiresByType text/css "access plus 1 month"
> > ExpiresByType text/javascript "access plus 1 month"
> > </Directory>
> >
> > Of course we can tweak the times, I just made up 1 month.
> >
> Is this how Expires work? ::
>
> * Client requests fp.o/static/fedora.css
> * Client receives fedora.css with an Expires line of 1 month
> * For the next month, the client does not retrieve new versions of
> fedora.css.
>
> If so, we're either going to want to keep the Expires time pretty low (an
> hour or less) or start adding version information into all of our static
> resources.
>

That's a great question and one I've been curious about as well. how's
that whole system supposed to work? What if I close the browser? Will
it still use the cache if it was set to 1 month?

-Mike

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 
Old 01-09-2010, 01:37 AM
Brennan Ashton
 
Default yslow website stats

On Fri, Jan 8, 2010 at 9:04 PM, Mike McGrath <mmcgrath@redhat.com> wrote:
> On Fri, 8 Jan 2010, Toshio Kuratomi wrote:
>
>> On Fri, Jan 08, 2010 at 10:42:35AM -0800, Darren VanBuren wrote:
>> > On the matter of Expires, here's what would need to be added to an
>> > Apache config, assuming static stuff is in /srv/web/static:
>> >
>> > <Directory /srv/web/static>
>> > ExpiresByType image/gif "access plus 1 month"
>> > ExpiresByType image/png "access plus 1 month"
>> > ExpiresByType text/css "access plus 1 month"
>> > ExpiresByType text/javascript "access plus 1 month"
>> > </Directory>
>> >
>> > Of course we can tweak the times, I just made up 1 month.
>> >
>> Is this how Expires work? ::
>>
>> * * Client requests fp.o/static/fedora.css
>> * * Client receives fedora.css with an Expires line of 1 month
>> * * For the next month, the client does not retrieve new versions of
>> * * fedora.css.
>>
>> If so, we're either going to want to keep the Expires time pretty low (an
>> hour or less) or start adding version information into all of our static
>> resources.
>>
>
> That's a great question and one I've been curious about as well. *how's
> that whole system supposed to work? *What if I close the browser? *Will
> it still use the cache if it was set to 1 month?
>
> * * * *-Mike

My understanding from the limited amount of cache stuff I have done is
that if you use Expires and have it set for a month, then the data
will sit on the browser's computer for that time, or until the cache
is manually cleared. However thanks to HTTP 1.1 we now have access to
cache-control headers [1] which includes "must-revalidate" and
"proxy-revalidate" which creates a check to see if the data is the
most recent or if it needs to be resent, this is more traffic, but can
increase confidence that it is the newest data.

This:
Cache-Control: max-age=3600, must-revalidate

would require a check, and also expire every 3600 seconds.


[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9

--Brennan Ashton

_______________________________________________
Fedora-infrastructure-list mailing list
Fedora-infrastructure-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
 

Thread Tools




All times are GMT. The time now is 01:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org