Hi,

There are several YSlow beacon params that are not described in the help pages,
can anyone give further insight?

's' - space id of the page. Not clear to me what the space id is

Some objects under the 'comps' key have a 'cr' and a 'cs' key, what do these
describe?

Are 'yxhr' and 'yxhrmethod' really duplicate info?

Thanks,
- Ivo

The documentation mentions a beacon parameter that is the "space id of the
page", what does this refer to?

Thanks,

- Ivo

That isn't what is happening. In the statistics section it is supposed to show
you how many requests take place with an empty cache compared against a "filled"
cache. They both say there is only one http request. In the "components" section
it says there is only 1 document and nothing else, even though that is supposed
to list cached documents as well. Even if I clear my cache, it still says there
was only one http request, even though I can see my browser performing two by
using TamperData and by monitoring my access logs.

Hi Mike

I dont think it is caused by YSlow not recognizing xsl files. I think it is because your stylesheet is cached in the browsers cache and YSlow only shows those elements that were downloaded. I might be wrong with that - but I think this is what happens

I just tried it with the FREE dynaTrace AJAX Edition (http://ajax.dynatrace.com). There I can see the file being downloaded - even if I already had it in the cache and it was retreived from the cache.
dynaTrace AJAX Edition also shows me how much time was spent in Rendering the page - and - if there would be JavaScript on the page - how long that took to execute

--- In exceptional-performance@yahoogroups.com, "mikecardwell321" <mikecardwell321@...> wrote:
>
> Hi,
>
> YSlow doesn't seem to support XSLT. If my site returns a .xml file, which then requests a stylesheet, it all works fine. Except YSlow reckons there was only one http request. Example:
>
> https://secure.grepular.com/yslow/
>
> That simple page causes two HTTP requests, but the second request for https://secure.grepular.com/yslow/stylesheet.xsl doesn't appear in YSlow.
>
> Mike
>

Hi,

YSlow doesn't seem to support XSLT. If my site returns a .xml file, which then
requests a stylesheet, it all works fine. Except YSlow reckons there was only
one http request. Example:

https://secure.grepular.com/yslow/

That simple page causes two HTTP requests, but the second request for
https://secure.grepular.com/yslow/stylesheet.xsl doesn't appear in YSlow.

Mike

Thanks to all the feedback we got from people like you who work in the Web Site
Performance field, dynaTrace today officially released version 1.4 of its FREE
dynaTrace AJAX Edition.

Check out the Step-By-Step Guide that shows how to use this tool on Google Maps:
http://blog.dynatrace.com/2009/11/17/a-step-by-step-guide-to-dynatrace-ajax-edit\
ion-available-today-for-public-download/
Download the tool at http://ajax.dynatrace.com
Join the community at http://ajax.dynatrace.com/pages/community/default.aspx

Thanks again for all the feedback and involvement we received so far

Cheers
Andi

You can also use $GLOBALS['HTTP_RAW_POST_DATA']

Bruno

--- In exceptional-performance@yahoogroups.com, "cervantes_vive"
<cervantes_vive@...> wrote:
>
> Found my answer, thought I should reply for future reference
>
> http://www.php.net/manual/en/wrappers.php.php:
>
> "php://input allows you to read raw POST data."
>
> so the relevant code is:
>
> $json_content = file_get_contents('php://input');
>
> Thanks,
>
> - Ivo
>
> --- In exceptional-performance@yahoogroups.com, "cervantes_vive"
<cervantes_vive@> wrote:
> >
> > Hello folks,
> >
> > I am attempting to parse out YSlow POST beacon data using PHP. I have
"extensions.yslow.beaconInfo" set to "all" so all data is submitted via POST
with the data as JSON in the document body.
> >
> > Does anyone know how to read such data in PHP? The POST is not
x-www-form-urlencoded so the JSON in the body is no available thru the
traditional $_POST variable.
> >
> > Any pointers are greatly appreciated.
> >
> > - Ivo
> >
>

Found my answer, thought I should reply for future reference

http://www.php.net/manual/en/wrappers.php.php:

"php://input allows you to read raw POST data."

so the relevant code is:

$json_content = file_get_contents('php://input');

Thanks,

- Ivo

--- In exceptional-performance@yahoogroups.com, "cervantes_vive"
<cervantes_vive@...> wrote:
>
> Hello folks,
>
> I am attempting to parse out YSlow POST beacon data using PHP. I have
"extensions.yslow.beaconInfo" set to "all" so all data is submitted via POST
with the data as JSON in the document body.
>
> Does anyone know how to read such data in PHP? The POST is not
x-www-form-urlencoded so the JSON in the body is no available thru the
traditional $_POST variable.
>
> Any pointers are greatly appreciated.
>
> - Ivo
>

Hello folks,

I am attempting to parse out YSlow POST beacon data using PHP. I have
"extensions.yslow.beaconInfo" set to "all" so all data is submitted via POST
with the data as JSON in the document body.

Does anyone know how to read such data in PHP? The POST is not
x-www-form-urlencoded so the JSON in the body is no available thru the
traditional $_POST variable.

Any pointers are greatly appreciated.

- Ivo

Disabled, restarted FF, Enabled, restarted FF, Run produces peeler error
undefined comp?

Funnily enough, I was with DreamHost until a massive screwup/outage/outrage in
2007 (I think it was 2007) whereupon I switched to HostUpon - at $110 for 2
years with unlimited webspac and unlimited bandwith, it was exceptional value at
the time and on balance I think it was money well spent.

To date they've mostly been pretty good, although recently there has been some
really glaring performance degradation; the really awful thing is the
variability... I will whine about page loads that are like swimming through
porridge, and fifteen minutes later the same page is loading with a TTFB of
1.5sec... and fifteen hours later it will be 20 seconds again.

I have shell and SCP/SFTP access (I use PuTTY and WinSCP), and can edit htaccess
- which means that I can influence the server config variables like Expires,
some Rewrite rules and DEFLATE. I can also change PHP variables within htaccess
(that's how I changed my include_path,and activated zlib.output_compression) and
I'm pretty sure I could have a custom PHP.ini if I could be bothered.

IT had not crossed my mind to try to get a reading on server load myself - I'll
havea crack at doing that this weekend.

Thanks again


GT

--- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@...>
wrote:
>
> Dreamhost (the hosting provider I use for WebPagetest) has persistent
> connections enabled in their stock apache config.  You can break it using
> htaccess which is what I did in my testing but you can't force it on if it
> isn't enabled.
>
> I wouldn't necessarily give up on shared hosting completely, it may just be
> that the provider you are using may suck more than others.  I can't control
> the apache configs themselves but I can run  custom php installs (or just
> php.ini on their install) and a whole suite of other stuff.  I have full
> shell access (though not root obviously) and when there were load problems
> they took care of them by moving heavy offenders off to other servers.
> There are also multiple tiers where you can still get a virtual host with
> root access without having to shell out for a full dedicated server.
>
> It may not hurt to stand up a completely stupid html page that references a
> bunch of images (no htaccess at all) and see what the behavior is.  If there
> are still  not persistent connections then you have a pretty good example to
> shoot to the provider and tell them their config is broken (though the pain
> you are seeing on the base page may mean they are way over-subscribed
> anyway).  Do you have shell access of any kind?  If so check to see what the
> load averages are (and if not, drop in a php script that can report them to
> you) then take that to support and push them to fix it.
>
> -Pat
>
>
>
> From: exceptional-performance@yahoogroups.com
> [mailto:exceptional-performance@yahoogroups.com] On Behalf Of GT
> Sent: Friday, November 13, 2009 4:18 PM
> To: exceptional-performance@yahoogroups.com
> Subject: [exceptional-performance] Re: 'Waiting for server response' and
> flush()
>
>
>
>
>
> Oh, and one final thing: I reverted one page on the site (a 'Stock
> Workbench') to a non-optimised version: reverted sprited images to
> individual images, left javascript files as individual files rather than
> combining them, and left some js files (small ones) non-minified.
>
> http://www.marketmentat.com/stocks/stock-workbench/?ASXCode=FWD
>
> I'm going to go through it step by step (it will require some code changes -
> to move some score indicators to CSS images rather than img tags, for
> instance) and record the amount of time each rule saves.
>
> Pat: I notice on your blog post that you mention that you used a 'shared
> hosting' type environment in your example
> (http://blog.patrickmeenan.com/2009/05/optimization-impact.html); how did
> you handle the 'keep-alive' enabling? I have not found any guidance on how
> to do that in .htaccess (and I don't want to 'suck it and see' on the basis
> that it might do something nefarious for other users on the shared host).
>
> I'll cross-post ask the question on your blog, but because the thread is one
> from back in May I thought I would ask it here as well.
>
> Even for the largely-non-optimised page I mentioned above, the thing that's
> killing its response times is mostly the DIABOLICAL TTFB for the initial
> server response (and that is repeated for one of the PHP calls... and I know
> for a fact that the PHP processing for that script takes less than half a
> second).
>
> 7.8sec of the 9sec page load time is due to those two TTFBs - it's as if a
> monkey has to wait to switch the server on, then has to load PHP from a 5"
> floppy when a PHP call is made.
>
> --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> , "GT" <GT@> wrote:
> >
> > Thanks for the info, Pat and Philip.
> >
> > Oddly enough, when I contacted my webhost they maintained that keep-alive
> is enabled globally on the server and that perhaps it was Wordpress that was
> making it switch off. That doesn't really seem likely, to me.
> >
> > I can only issue Apache directives through .htaccess, so it certainly
> isn't me who's switching it off on my pages. (My .htaccess is very simple -
> two redirects, two 'deny from' for rogue IPs, and compression and expiration
> stuff. Nothing more.)
> >
> > For some pages - ones with more components - the waterfall indicates that
> there can be up to 5 lots of 300-500ms per page in connection 'costs' -
> representing 15% of page load time.
> >
> > That, coupled with a TTFB of up to 5 or 6 seconds (and some days when the
> thing is being precocious, THIRTY seconds), puts me in 'throw the hands in
> the air and shell out for higher class hosting" territory.
> >
> > So I reckon I'm going to take on a CloudLayer 'bare metal' machine - quad
> core, 4G of dedicated RAM, a 250Gb dedicated HDD and 6TB of traffic a month.
> More importantly, root access and control over PHP, mySQL and Apache
> configs.
> >
> > I see no reason why I should not get served pages to behave the way my
> localhost versions behave (give or take roundtrips to the server, obviously
> - but I emulate that on localhost by stalling page delivery by three times
> the remote server's ping time).
> >
> > Cheers
> >
> >
> > GT
> >
> >
> >
> > --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> , "Patrick Meenan"
> <PatMeenan@> wrote:
> > >
> > > The browsers will all make multiple connections with persistent
> connections
> > > enabled. If everything is served from a single domain (like with most
> sites
> > > on shared hosting) this can cut the page load almost in half. It may not
> be
> > > in the Yahoo rules because it is almost inherent in the HTTP 1.1 spec
> but it
> > > is amazing how many sites have it disabled. Some shared hosting
> providers
> > > may have it disabled for scaling reasons but that's not really a good
> excuse
> > > and you should contact them to see if they can enable it.
> > >
> > > Here is an experiment I did a few months ago that looked at the impact
> of
> > > various optimizations:
> > > http://blog.patrickmeenan.com/2009/05/optimization-impact.html
> > >
> > > Enabling persistent connections (at least in this one case) cut the load
> > > time in half. This is pretty much what you would expect since each
> > > connection adds another round trip and most of the time the browser
> spends
> > > is waiting on the round trip for the request so without persistent
> > > connections you double the round trips. Even if you move static content
> to
> > > a different domain, I HIGHLY encourage you to get persistent connections
> > > enabled for that domain. It is usually configured in httpd.conf but
> there
> > > are some .htaccess rules that can force it to disable (particularly if
> there
> > > are any rules forcing HTTP 1.0 which is sometimes configured for IE).
> > >
> > > Looking at your test results specifically, it looks like it would shave
> > > ~500ms from the page load from the VA test system but the savings would
> get
> > > larger the further away the users are.
> > >
> > > It's somewhat more esoteric, but even beyond the round trip for the
> > > connection, each time you set up a new connection TCP goes back into
> > > slow-start mode so constantly resetting the connections makes the actual
> > > downloads take longer as well
> > >
> (http://blog.patrickmeenan.com/2009/09/tcp-and-http-fighting-each-other-to.h
> > > tml)
> > >
> > > Thanks,
> > >
> > > -Pat
> > >
> > > From: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > [mailto:exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> ] On Behalf Of Philip
> Tellis
> > > Sent: Monday, November 09, 2009 5:18 PM
> > > To: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > Subject: Re: [exceptional-performance] Re: 'Waiting for server response'
> and
> > > flush()
> > >
> > >
> > >
> > >
> > >
> > > keep-alive can be good or bad depending on your situation. This is the
> > > apache doc about it: http://httpd.apache.org/docs/1.3/keepalive.html
> > >
> > > The idea is that you open just a single TCP connection between browser
> > > and server, and make multiple HTTP requests over that connection. This
> > > is good if you have a lot of resources on a single page that all come
> > > from the same server.
> > >
> > > Now the caveats.
> > >
> > > 1. I'm not sure if the browser will still make multiple parallel
> > > connections to the server or if it tries to push all requests over the
> > > same connection (you can easily test this though).
> > > 2. If you have too many resources, your server process can get tied up
> > > for a long time which means you can handle fewer simultaneous clients.
> > > 3. If you have a lot of resources (images, css, js), then you should
> > > really be using sprites and combining css files and js files.
> > >
> > > In the end, YMMV with Keep-Alive. try it, run it through some load
> > > testing and decide if you need it or not. Another thing you could do is
> > > to offload your static resources to a separate domain (if you can easily
>
> > > create subdomains, this will work), and set up keepalive only for that
> > > virtual host.
> > >
> > > Sometime on Nov 8, G dropped bits saying:
> > >
> > > > Hi again,
> > > >
> > > > Interesting development (and solution to the strange login redirect).
> > > >
> > > > It turned out that a plugin (which shall remaion nameless) was causing
> the
> > > redirection to the login panel.
> > > >
> > > > Stranger still: once the plugin was removed, the TTFB dropped to 1.55
> sec,
> > > and the document complete fell to 4sec.
> > > >
> > > > The webpagetest.org Performance Review recommended using 'Keep-Alive'
> -
> > > about which I know precisely ZERO, although I assume it might have
> something
> > > to do with keeping open the server connection (thus removing the
> requirement
> > > for page assets to -reform a server connection).
> > > >
> > > > I've found precious little on teh.Google - and the phrase 'keep-alive'
> > > does not appear in http://developer.yahoo.com/performance/rules.html at
> all
> > > (nor does the word 'persistent').
> > > >
> > > > Can anyody offer any guidance on how such a thing is implemented? It
> seems
> > > to be a candidate for either httpd.conf (over which I dont' have any
> control
> > > - shared hosting) or htaccess.
> > > >
> > > > Cheers
> > > >
> > > >
> > > > GT
> > > >
> > > > --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > <mailto:exceptional-performance%40yahoogroups.com> , "GT" <GT@> wrote:
> > > >>
> > > >> Thanks for your response, Pat.
> > > >>
> > > >> I tried running a test of that sort some days ago, but for some odd
> > > reason my site redirected to a login page.
> > > >>
> > > >> The same thing happens with webpagetest.org - odd, that, since the
> site
> > > is supposed to be viewable by anyone.
> > > >>
> > > >> (As an aside I hope that doesn't happen to everyone who visits: if I
> log
> > > out and then navigate to the site with a cleared cache, I get the front
> page
> > > that I expect.)
> > > >>
> > > >> The 'time to first byte' in the Summary was a stonking 5.3 seconds
> for
> > > the front page the first time I ran that test: the DNS lookup and
> connection
> > > time were normal (66 and 88 msec respectively).
> > > >>
> > > >> There are some odd things that happen in the 'detailed' pane in the
> > > request trace: (the URL sought is http://www.marketmentat.com )
> > > >>
> > > >> (1) http://www.marketmentat.com - TTFB 2.02sec
> > > >> (2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
> > > >> (3) [login redirect URL] - offset 4.77s TTFB 5.01
> > > >>
> > > >> If I use http://www.marketmentat.com/ (add trailing slash), it
> becomes
> > > >>
> > > >> (1) http://www.marketmentat.com/ - TTFB 1.19sec
> > > >> (2) login redirect URL - offset 1.37sec, TTFB 1.20sec
> > > >>
> > > >> I find it staggering that the trailing slash makes such a difference.
> > > >>
> > > >> Job 1 is obviously figuring out why the redirect to the login page
> > > occurs. The 'start offset' of the login page is 4.77sec, so I am
> thinking
> > > that if the redirect was not in force there would be at least some
> savings.
> > > >>
> > > >> Cheerio
> > > >>
> > > >>
> > > >> GT
> > > >>
> > > >> --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > <mailto:exceptional-performance%40yahoogroups.com> , "Patrick Meenan"
> > > <PatMeenan@> wrote:
> > > >>>
> > > >>> I did a bulk analysis a few months ago at all of the tests that had
> been
> > > >>> submitted to WebPagetest <http://www.webpagetest.org/> here (24k
> unique
> > > >>> urls): http://www.webpagetest.org/forums/showthread.php?tid=22
> > > >>>
> > > >>>
> > > >>>
> > > >>> One of the stats I looked at was the Time To First Byte (which as I
> > > measure
> > > >>> it includes the DNS, initial socket connect and time for the server
> to
> > > send
> > > >>> the first bit of response back).
> > > >>>
> > > >>>
> > > >>>
> > > >>> The knee in the curve for TTFB is around 2 seconds with 90% of the
> sites
> > > >>> coming back faster than that (76% of the sites came back under
> 500ms) -
> > > and
> > > >>> this is including 50ms * 3 of Round-Trip-Time for last-mile network
> > > latency.
> > > >>> 3 seconds would be around the 95th percentile, 4 at the 96th
> percentile
> > > and
> > > >>> 9 seconds at the 98th percentile (with higher being worse in this
> case -
> > > 98%
> > > >>> of sites tested were faster).
> > > >>>
> > > >>>
> > > >>>
> > > >>> If you run a test on WebPagetest <http://www.webpagetest.org/> you
> can
> > > >>> pretty much figure out what the RTT to the server is by looking at
> the
> > > time
> > > >>> for the socket connect on the base page (this would be the PING
> time).
> > > The
> > > >>> VAST majority of your time is going to be coming from server
> resources -
> > > >>> unless your hosting company is in the moon J
> > > >>>
> > > >>>
> > > >>>
> > > >>> Thanks,
> > > >>>
> > > >>>
> > > >>>
> > > >>> -Pat
> > > >>>
> > > >>>
> > > >>>
> > > >>> From: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > <mailto:exceptional-performance%40yahoogroups.com>
> > > >>> [mailto:exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > <mailto:exceptional-performance%40yahoogroups.com> ] On Behalf Of GT
> > > >>> Sent: Thursday, November 05, 2009 4:56 PM
> > > >>> To: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> > > <mailto:exceptional-performance%40yahoogroups.com>
> > > >>> Subject: [exceptional-performance] 'Waiting for server response' and
> > > flush()
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>> Hey y'all
> > > >>>
> > > >>> My site's performance has benefited greatly from YSlow and the
> various
> > > >>> hints: the next step for me is to try to combine images into
> sprites...
> > > I
> > > >>> was staggered to see how much slack there is in loading the
> underlying
> > > >>> images that are so fundamental to even the most basic website.
> > > >>>
> > > >>> FireBug/YSlow has also shown me is that not enough is made of the
> > > benefits
> > > >>> of a PHP 'flush()' directive at the first sensible opportunity; this
> is
> > > easy
> > > >>> to overlook but has significant benefits.
> > > >>>
> > > >>> One thing that I have noticed though, is that I get significant (>3
> or 4
> > > >>> seconds - and up to NINE seconds) "Waiting for server response" on
> the
> > > >>> initial GET of any page on my server.
> > > >>>
> > > >>> The issue is (as I would expect) not as bad on my local clone of the
> > > site,
> > > >>> but it's still upwards of 2-3sec and it easily the largest component
> in
> > > the
> > > >>> delay between hitting the URL and getting a 'navigable' page.
> > > >>>
> > > >>> It would be terrific if someone could prepare a little guide as to
> what
> > > to
> > > >>> expect as a 'normal' server response time - ow it relates (if at
> all) to
> > > >>> PING and TRACERT times and how much is determined by server
> resources.
> > > After
> > > >>> all, I can run a debugger and see how long the server takes to
> > > 'sticky-tape'
> > > >>> the actual page together... and it's nowhere NEAR 3 seconds (it's
> more
> > > like
> > > >>> 0.3) - so it's not an issue of the server making the browser wait 7
> > > seconds
> > > >>> while it preps the page.
> > > >>>
> > > >>> I tried using teh.Google (gasp!) to get some answers, but no joy.
> > > >>>
> > > >>> Cheerio
> > > >>>
> > > >>> GT
> > > >>> Australia
> > > >>>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > > > ------------------------------------
> > > >
> > > >
> > >
> >
>

Oh, and one final thing: I reverted one page on the site (a 'Stock Workbench')
to a non-optimised version: reverted sprited images to individual images, left
javascript files as individual files rather than combining them, and left some
js files (small ones) non-minified.

http://www.marketmentat.com/stocks/stock-workbench/?ASXCode=FWD

I'm going to go through it step by step (it will require some code changes - to
move some score indicators to CSS images rather than img tags, for instance) and
record the amount of time each rule saves.


Pat: I notice on your blog post that you mention that you used a 'shared
hosting' type environment in your example
(http://blog.patrickmeenan.com/2009/05/optimization-impact.html); how did you
handle the 'keep-alive' enabling? I have not found any guidance on how to do
that in .htaccess (and I don't want to 'suck it and see' on the basis that it
might do something nefarious for other users on the shared host).

I'll cross-post ask the question on your blog, but because the thread is one
from back in May I thought I would ask it here as well.

Even for the largely-non-optimised page I mentioned above, the thing that's
killing its response times is mostly the DIABOLICAL TTFB for the initial server
response (and that is repeated for one of the PHP calls... and I know for a fact
that the PHP processing for that script takes less than half a second).

7.8sec of the 9sec page load time is due to those two TTFBs - it's as if a
monkey has to wait to switch the server on, then has to load PHP from a 5"
floppy when a PHP call is made.



--- In exceptional-performance@yahoogroups.com, "GT" <GT@...> wrote:
>
> Thanks for the info, Pat and Philip.
>
> Oddly enough, when I contacted my webhost they maintained that keep-alive is
enabled globally on the server and that perhaps it was Wordpress that was making
it switch off. That doesn't really seem likely, to me.
>
> I can only issue Apache directives through .htaccess, so it certainly isn't me
who's switching it off on my pages. (My .htaccess is very simple - two
redirects, two 'deny from' for rogue IPs, and compression and expiration stuff.
Nothing more.)
>
> For some pages - ones with more components - the waterfall indicates that
there can be up to 5 lots of 300-500ms per page in connection 'costs' -
representing 15% of page load time.
>
> That, coupled with a TTFB of up to 5 or 6 seconds (and some days when the
thing is being precocious, THIRTY seconds), puts me in 'throw the hands in the
air and shell out for higher class hosting" territory.
>
> So I reckon I'm going to take on a CloudLayer 'bare metal' machine  - quad
core, 4G of dedicated RAM, a 250Gb dedicated HDD and 6TB of traffic a month.
More importantly, root access and control over PHP, mySQL and Apache configs.
>
> I see no reason why I should not get served pages to behave the way my
localhost versions behave (give or take roundtrips to the server, obviously -
but I emulate that on localhost by stalling page delivery by three times the
remote server's ping time).
>
> Cheers
>
>
> GT
>
>
>
> --- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@>
wrote:
> >
> > The browsers will all make multiple connections with persistent connections
> > enabled.  If everything is served from a single domain (like with most sites
> > on shared hosting) this can cut the page load almost in half.  It may not be
> > in the Yahoo rules because it is almost inherent in the HTTP 1.1 spec but it
> > is amazing how many sites have it disabled.  Some shared hosting providers
> > may have it disabled for scaling reasons but that's not really a good excuse
> > and you should contact them to see if they can enable it.
> >
> > Here is an experiment I did a few months ago that looked at the impact of
> > various optimizations:
> > http://blog.patrickmeenan.com/2009/05/optimization-impact.html
> >
> > Enabling persistent connections (at least in this one case) cut the load
> > time in half.  This is pretty much what you would expect since each
> > connection adds another round trip and most of the time the browser spends
> > is waiting on the round trip for the request so without persistent
> > connections you double the round trips.  Even if you move static content to
> > a different domain, I HIGHLY encourage you to get persistent connections
> > enabled for that domain.  It is usually configured in httpd.conf but there
> > are some .htaccess rules that can force it to disable (particularly if there
> > are any rules forcing HTTP 1.0 which is sometimes configured for IE).
> >
> > Looking at your test results specifically, it looks like it would shave
> > ~500ms from the page load from the VA test system but the savings would get
> > larger the further away the users are.
> >
> > It's somewhat more esoteric, but even beyond the round trip for the
> > connection, each time you set up a new connection TCP goes back into
> > slow-start mode so constantly resetting the connections makes the actual
> > downloads take longer as well
> > (http://blog.patrickmeenan.com/2009/09/tcp-and-http-fighting-each-other-to.h
> > tml)
> >
> > Thanks,
> >
> > -Pat
> >
> > From: exceptional-performance@yahoogroups.com
> > [mailto:exceptional-performance@yahoogroups.com] On Behalf Of Philip Tellis
> > Sent: Monday, November 09, 2009 5:18 PM
> > To: exceptional-performance@yahoogroups.com
> > Subject: Re: [exceptional-performance] Re: 'Waiting for server response' and
> > flush()
> >
> >
> >
> >
> >
> > keep-alive can be good or bad depending on your situation. This is the
> > apache doc about it: http://httpd.apache.org/docs/1.3/keepalive.html
> >
> > The idea is that you open just a single TCP connection between browser
> > and server, and make multiple HTTP requests over that connection. This
> > is good if you have a lot of resources on a single page that all come
> > from the same server.
> >
> > Now the caveats.
> >
> > 1. I'm not sure if the browser will still make multiple parallel
> > connections to the server or if it tries to push all requests over the
> > same connection (you can easily test this though).
> > 2. If you have too many resources, your server process can get tied up
> > for a long time which means you can handle fewer simultaneous clients.
> > 3. If you have a lot of resources (images, css, js), then you should
> > really be using sprites and combining css files and js files.
> >
> > In the end, YMMV with Keep-Alive. try it, run it through some load
> > testing and decide if you need it or not. Another thing you could do is
> > to offload your static resources to a separate domain (if you can easily
> > create subdomains, this will work), and set up keepalive only for that
> > virtual host.
> >
> > Sometime on Nov 8, G dropped bits saying:
> >
> > > Hi again,
> > >
> > > Interesting development (and solution to the strange login redirect).
> > >
> > > It turned out that a plugin (which shall remaion nameless) was causing the
> > redirection to the login panel.
> > >
> > > Stranger still: once the plugin was removed, the TTFB dropped to 1.55 sec,
> > and the document complete fell to 4sec.
> > >
> > > The webpagetest.org Performance Review recommended using 'Keep-Alive' -
> > about which I know precisely ZERO, although I assume it might have something
> > to do with keeping open the server connection (thus removing the requirement
> > for page assets to -reform a server connection).
> > >
> > > I've found precious little on teh.Google - and the phrase 'keep-alive'
> > does not appear in http://developer.yahoo.com/performance/rules.html at all
> > (nor does the word 'persistent').
> > >
> > > Can anyody offer any guidance on how such a thing is implemented? It seems
> > to be a candidate for either httpd.conf (over which I dont' have any control
> > - shared hosting) or htaccess.
> > >
> > > Cheers
> > >
> > >
> > > GT
> > >
> > > --- In exceptional-performance@yahoogroups.com
> > <mailto:exceptional-performance%40yahoogroups.com> , "GT" <GT@> wrote:
> > >>
> > >> Thanks for your response, Pat.
> > >>
> > >> I tried running a test of that sort some days ago, but for some odd
> > reason my site redirected to a login page.
> > >>
> > >> The same thing happens with webpagetest.org - odd, that, since the site
> > is supposed to be viewable by anyone.
> > >>
> > >> (As an aside I hope that doesn't happen to everyone who visits: if I log
> > out and then navigate to the site with a cleared cache, I get the front page
> > that I expect.)
> > >>
> > >> The 'time to first byte' in the Summary was a stonking 5.3 seconds for
> > the front page the first time I ran that test: the DNS lookup and connection
> > time were normal (66 and 88 msec respectively).
> > >>
> > >> There are some odd things that happen in the 'detailed' pane in the
> > request trace: (the URL sought is http://www.marketmentat.com )
> > >>
> > >> (1) http://www.marketmentat.com - TTFB 2.02sec
> > >> (2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
> > >> (3) [login redirect URL] - offset 4.77s TTFB 5.01
> > >>
> > >> If I use http://www.marketmentat.com/ (add trailing slash), it becomes
> > >>
> > >> (1) http://www.marketmentat.com/ - TTFB 1.19sec
> > >> (2) login redirect URL - offset 1.37sec, TTFB 1.20sec
> > >>
> > >> I find it staggering that the trailing slash makes such a difference.
> > >>
> > >> Job 1 is obviously figuring out why the redirect to the login page
> > occurs. The 'start offset' of the login page is 4.77sec, so I am thinking
> > that if the redirect was not in force there would be at least some savings.
> > >>
> > >> Cheerio
> > >>
> > >>
> > >> GT
> > >>
> > >> --- In exceptional-performance@yahoogroups.com
> > <mailto:exceptional-performance%40yahoogroups.com> , "Patrick Meenan"
> > <PatMeenan@> wrote:
> > >>>
> > >>> I did a bulk analysis a few months ago at all of the tests that had been
> > >>> submitted to WebPagetest <http://www.webpagetest.org/> here (24k unique
> > >>> urls): http://www.webpagetest.org/forums/showthread.php?tid=22
> > >>>
> > >>>
> > >>>
> > >>> One of the stats I looked at was the Time To First Byte (which as I
> > measure
> > >>> it includes the DNS, initial socket connect and time for the server to
> > send
> > >>> the first bit of response back).
> > >>>
> > >>>
> > >>>
> > >>> The knee in the curve for TTFB is around 2 seconds with 90% of the sites
> > >>> coming back faster than that (76% of the sites came back under 500ms) -
> > and
> > >>> this is including 50ms * 3 of Round-Trip-Time for last-mile network
> > latency.
> > >>> 3 seconds would be around the 95th percentile, 4 at the 96th percentile
> > and
> > >>> 9 seconds at the 98th percentile (with higher being worse in this case -
> > 98%
> > >>> of sites tested were faster).
> > >>>
> > >>>
> > >>>
> > >>> If you run a test on WebPagetest <http://www.webpagetest.org/> you can
> > >>> pretty much figure out what the RTT to the server is by looking at the
> > time
> > >>> for the socket connect on the base page (this would be the PING time).
> > The
> > >>> VAST majority of your time is going to be coming from server resources -
> > >>> unless your hosting company is in the moon J
> > >>>
> > >>>
> > >>>
> > >>> Thanks,
> > >>>
> > >>>
> > >>>
> > >>> -Pat
> > >>>
> > >>>
> > >>>
> > >>> From: exceptional-performance@yahoogroups.com
> > <mailto:exceptional-performance%40yahoogroups.com>
> > >>> [mailto:exceptional-performance@yahoogroups.com
> > <mailto:exceptional-performance%40yahoogroups.com> ] On Behalf Of GT
> > >>> Sent: Thursday, November 05, 2009 4:56 PM
> > >>> To: exceptional-performance@yahoogroups.com
> > <mailto:exceptional-performance%40yahoogroups.com>
> > >>> Subject: [exceptional-performance] 'Waiting for server response' and
> > flush()
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> Hey y'all
> > >>>
> > >>> My site's performance has benefited greatly from YSlow and the various
> > >>> hints: the next step for me is to try to combine images into sprites...
> > I
> > >>> was staggered to see how much slack there is in loading the underlying
> > >>> images that are so fundamental to even the most basic website.
> > >>>
> > >>> FireBug/YSlow has also shown me is that not enough is made of the
> > benefits
> > >>> of a PHP 'flush()' directive at the first sensible opportunity; this is
> > easy
> > >>> to overlook but has significant benefits.
> > >>>
> > >>> One thing that I have noticed though, is that I get significant (>3 or 4
> > >>> seconds - and up to NINE seconds) "Waiting for server response" on the
> > >>> initial GET of any page on my server.
> > >>>
> > >>> The issue is (as I would expect) not as bad on my local clone of the
> > site,
> > >>> but it's still upwards of 2-3sec and it easily the largest component in
> > the
> > >>> delay between hitting the URL and getting a 'navigable' page.
> > >>>
> > >>> It would be terrific if someone could prepare a little guide as to what
> > to
> > >>> expect as a 'normal' server response time - ow it relates (if at all) to
> > >>> PING and TRACERT times and how much is determined by server resources.
> > After
> > >>> all, I can run a debugger and see how long the server takes to
> > 'sticky-tape'
> > >>> the actual page together... and it's nowhere NEAR 3 seconds (it's more
> > like
> > >>> 0.3) - so it's not an issue of the server making the browser wait 7
> > seconds
> > >>> while it preps the page.
> > >>>
> > >>> I tried using teh.Google (gasp!) to get some answers, but no joy.
> > >>>
> > >>> Cheerio
> > >>>
> > >>> GT
> > >>> Australia
> > >>>
> > >>
> > >
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > >
> >
>

Thanks for the info, Pat and Philip.

Oddly enough, when I contacted my webhost they maintained that keep-alive is
enabled globally on the server and that perhaps it was Wordpress that was making
it switch off. That doesn't really seem likely, to me.

I can only issue Apache directives through .htaccess, so it certainly isn't me
who's switching it off on my pages. (My .htaccess is very simple - two
redirects, two 'deny from' for rogue IPs, and compression and expiration stuff.
Nothing more.)

For some pages - ones with more components - the waterfall indicates that there
can be up to 5 lots of 300-500ms per page in connection 'costs' - representing
15% of page load time.

That, coupled with a TTFB of up to 5 or 6 seconds (and some days when the thing
is being precocious, THIRTY seconds), puts me in 'throw the hands in the air and
shell out for higher class hosting" territory.

So I reckon I'm going to take on a CloudLayer 'bare metal' machine  - quad core,
4G of dedicated RAM, a 250Gb dedicated HDD and 6TB of traffic a month. More
importantly, root access and control over PHP, mySQL and Apache configs.

I see no reason why I should not get served pages to behave the way my localhost
versions behave (give or take roundtrips to the server, obviously - but I
emulate that on localhost by stalling page delivery by three times the remote
server's ping time).

Cheers


GT



--- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@...>
wrote:
>
> The browsers will all make multiple connections with persistent connections
> enabled.  If everything is served from a single domain (like with most sites
> on shared hosting) this can cut the page load almost in half.  It may not be
> in the Yahoo rules because it is almost inherent in the HTTP 1.1 spec but it
> is amazing how many sites have it disabled.  Some shared hosting providers
> may have it disabled for scaling reasons but that's not really a good excuse
> and you should contact them to see if they can enable it.
>
> Here is an experiment I did a few months ago that looked at the impact of
> various optimizations:
> http://blog.patrickmeenan.com/2009/05/optimization-impact.html
>
> Enabling persistent connections (at least in this one case) cut the load
> time in half.  This is pretty much what you would expect since each
> connection adds another round trip and most of the time the browser spends
> is waiting on the round trip for the request so without persistent
> connections you double the round trips.  Even if you move static content to
> a different domain, I HIGHLY encourage you to get persistent connections
> enabled for that domain.  It is usually configured in httpd.conf but there
> are some .htaccess rules that can force it to disable (particularly if there
> are any rules forcing HTTP 1.0 which is sometimes configured for IE).
>
> Looking at your test results specifically, it looks like it would shave
> ~500ms from the page load from the VA test system but the savings would get
> larger the further away the users are.
>
> It's somewhat more esoteric, but even beyond the round trip for the
> connection, each time you set up a new connection TCP goes back into
> slow-start mode so constantly resetting the connections makes the actual
> downloads take longer as well
> (http://blog.patrickmeenan.com/2009/09/tcp-and-http-fighting-each-other-to.h
> tml)
>
> Thanks,
>
> -Pat
>
> From: exceptional-performance@yahoogroups.com
> [mailto:exceptional-performance@yahoogroups.com] On Behalf Of Philip Tellis
> Sent: Monday, November 09, 2009 5:18 PM
> To: exceptional-performance@yahoogroups.com
> Subject: Re: [exceptional-performance] Re: 'Waiting for server response' and
> flush()
>
>
>
>
>
> keep-alive can be good or bad depending on your situation. This is the
> apache doc about it: http://httpd.apache.org/docs/1.3/keepalive.html
>
> The idea is that you open just a single TCP connection between browser
> and server, and make multiple HTTP requests over that connection. This
> is good if you have a lot of resources on a single page that all come
> from the same server.
>
> Now the caveats.
>
> 1. I'm not sure if the browser will still make multiple parallel
> connections to the server or if it tries to push all requests over the
> same connection (you can easily test this though).
> 2. If you have too many resources, your server process can get tied up
> for a long time which means you can handle fewer simultaneous clients.
> 3. If you have a lot of resources (images, css, js), then you should
> really be using sprites and combining css files and js files.
>
> In the end, YMMV with Keep-Alive. try it, run it through some load
> testing and decide if you need it or not. Another thing you could do is
> to offload your static resources to a separate domain (if you can easily
> create subdomains, this will work), and set up keepalive only for that
> virtual host.
>
> Sometime on Nov 8, G dropped bits saying:
>
> > Hi again,
> >
> > Interesting development (and solution to the strange login redirect).
> >
> > It turned out that a plugin (which shall remaion nameless) was causing the
> redirection to the login panel.
> >
> > Stranger still: once the plugin was removed, the TTFB dropped to 1.55 sec,
> and the document complete fell to 4sec.
> >
> > The webpagetest.org Performance Review recommended using 'Keep-Alive' -
> about which I know precisely ZERO, although I assume it might have something
> to do with keeping open the server connection (thus removing the requirement
> for page assets to -reform a server connection).
> >
> > I've found precious little on teh.Google - and the phrase 'keep-alive'
> does not appear in http://developer.yahoo.com/performance/rules.html at all
> (nor does the word 'persistent').
> >
> > Can anyody offer any guidance on how such a thing is implemented? It seems
> to be a candidate for either httpd.conf (over which I dont' have any control
> - shared hosting) or htaccess.
> >
> > Cheers
> >
> >
> > GT
> >
> > --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> , "GT" <GT@> wrote:
> >>
> >> Thanks for your response, Pat.
> >>
> >> I tried running a test of that sort some days ago, but for some odd
> reason my site redirected to a login page.
> >>
> >> The same thing happens with webpagetest.org - odd, that, since the site
> is supposed to be viewable by anyone.
> >>
> >> (As an aside I hope that doesn't happen to everyone who visits: if I log
> out and then navigate to the site with a cleared cache, I get the front page
> that I expect.)
> >>
> >> The 'time to first byte' in the Summary was a stonking 5.3 seconds for
> the front page the first time I ran that test: the DNS lookup and connection
> time were normal (66 and 88 msec respectively).
> >>
> >> There are some odd things that happen in the 'detailed' pane in the
> request trace: (the URL sought is http://www.marketmentat.com )
> >>
> >> (1) http://www.marketmentat.com - TTFB 2.02sec
> >> (2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
> >> (3) [login redirect URL] - offset 4.77s TTFB 5.01
> >>
> >> If I use http://www.marketmentat.com/ (add trailing slash), it becomes
> >>
> >> (1) http://www.marketmentat.com/ - TTFB 1.19sec
> >> (2) login redirect URL - offset 1.37sec, TTFB 1.20sec
> >>
> >> I find it staggering that the trailing slash makes such a difference.
> >>
> >> Job 1 is obviously figuring out why the redirect to the login page
> occurs. The 'start offset' of the login page is 4.77sec, so I am thinking
> that if the redirect was not in force there would be at least some savings.
> >>
> >> Cheerio
> >>
> >>
> >> GT
> >>
> >> --- In exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> , "Patrick Meenan"
> <PatMeenan@> wrote:
> >>>
> >>> I did a bulk analysis a few months ago at all of the tests that had been
> >>> submitted to WebPagetest <http://www.webpagetest.org/> here (24k unique
> >>> urls): http://www.webpagetest.org/forums/showthread.php?tid=22
> >>>
> >>>
> >>>
> >>> One of the stats I looked at was the Time To First Byte (which as I
> measure
> >>> it includes the DNS, initial socket connect and time for the server to
> send
> >>> the first bit of response back).
> >>>
> >>>
> >>>
> >>> The knee in the curve for TTFB is around 2 seconds with 90% of the sites
> >>> coming back faster than that (76% of the sites came back under 500ms) -
> and
> >>> this is including 50ms * 3 of Round-Trip-Time for last-mile network
> latency.
> >>> 3 seconds would be around the 95th percentile, 4 at the 96th percentile
> and
> >>> 9 seconds at the 98th percentile (with higher being worse in this case -
> 98%
> >>> of sites tested were faster).
> >>>
> >>>
> >>>
> >>> If you run a test on WebPagetest <http://www.webpagetest.org/> you can
> >>> pretty much figure out what the RTT to the server is by looking at the
> time
> >>> for the socket connect on the base page (this would be the PING time).
> The
> >>> VAST majority of your time is going to be coming from server resources -
> >>> unless your hosting company is in the moon J
> >>>
> >>>
> >>>
> >>> Thanks,
> >>>
> >>>
> >>>
> >>> -Pat
> >>>
> >>>
> >>>
> >>> From: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> >>> [mailto:exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com> ] On Behalf Of GT
> >>> Sent: Thursday, November 05, 2009 4:56 PM
> >>> To: exceptional-performance@yahoogroups.com
> <mailto:exceptional-performance%40yahoogroups.com>
> >>> Subject: [exceptional-performance] 'Waiting for server response' and
> flush()
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hey y'all
> >>>
> >>> My site's performance has benefited greatly from YSlow and the various
> >>> hints: the next step for me is to try to combine images into sprites...
> I
> >>> was staggered to see how much slack there is in loading the underlying
> >>> images that are so fundamental to even the most basic website.
> >>>
> >>> FireBug/YSlow has also shown me is that not enough is made of the
> benefits
> >>> of a PHP 'flush()' directive at the first sensible opportunity; this is
> easy
> >>> to overlook but has significant benefits.
> >>>
> >>> One thing that I have noticed though, is that I get significant (>3 or 4
> >>> seconds - and up to NINE seconds) "Waiting for server response" on the
> >>> initial GET of any page on my server.
> >>>
> >>> The issue is (as I would expect) not as bad on my local clone of the
> site,
> >>> but it's still upwards of 2-3sec and it easily the largest component in
> the
> >>> delay between hitting the URL and getting a 'navigable' page.
> >>>
> >>> It would be terrific if someone could prepare a little guide as to what
> to
> >>> expect as a 'normal' server response time - ow it relates (if at all) to
> >>> PING and TRACERT times and how much is determined by server resources.
> After
> >>> all, I can run a debugger and see how long the server takes to
> 'sticky-tape'
> >>> the actual page together... and it's nowhere NEAR 3 seconds (it's more
> like
> >>> 0.3) - so it's not an issue of the server making the browser wait 7
> seconds
> >>> while it preps the page.
> >>>
> >>> I tried using teh.Google (gasp!) to get some answers, but no joy.
> >>>
> >>> Cheerio
> >>>
> >>> GT
> >>> Australia
> >>>
> >>
> >
> >
> >
> >
> > ------------------------------------
> >
> >
>

Thank you for reporting this issue.
I've entered a bug report and will look into this soon.

--- In exceptional-performance@yahoogroups.com, "rowanlaurence"
<rowanlaurence@...> wrote:
>
> Yslow will tell you to minify inline scripts if they contain strings with
spaces in them IE:
>
> function(){
>    var x ='I like peas';
> }
>
> Obviously we can't miniy these and strings inside JS files dont get the same
warnings.
>
> Please can you have a look into it
>

http://en.oreilly.com/velocityfall09

In order to help the performance community stay in touch in between the
June Velocity conferences, O'Reilly is starting a series of OnLine
Conferences (aka, webinars) for Velocity. The first one is Dec 8. The
cost is $149. You can use "velfall09pcd" for a 25% discount. The
sessions include:

     * How Web Speed Affects Online Business KPIs - Hooman Behesti
(Strangeloop)
     * Faster Load Times Through Deferred JavaScript Evaluation - Charles
Jolley (Apple)
     * Load Balancing & Reverse Proxies with Varnish & More - Artur
Bergman (Wikia)
     * CouchDB from 10,000 Feet - Chris Anderson (couch.io)
     * A Roundtable Panel of Some of Your Favorite Velocity Web Ops Ninjas

I'll be adding 2-3 more sessions in the next week. I hope to hear you there!

-Steve

Yslow will tell you to minify inline scripts if they contain strings with spaces
in them IE:

function(){
    var x ='I like peas';
}

Obviously we can't miniy these and strings inside JS files dont get the same
warnings.

Please can you have a look into it

Thank you for reporting the issue.
The problem has been identified and I've uploaded version 2.0.2 that will fix
this problem.  It will be available for download once it passed the code review
by the mozillla team.


--- In exceptional-performance@yahoogroups.com, "lercherch" <lercherch@...>
wrote:
>
> Hi,
>
> the JSLint tool in YSlow doesn't work for me. It just displays a (Untitled)
page with the content "undefined".
>
> - Tried it on several (quite different) pages.
> - Tried it on Mac (Firefox 3.5.5, Firebug 1.4.3) and Windows (Firefox 3.5.3,
Firebug 1.4.5).
>
> Maybe it has something to do with this error:
> When I open Firebug on the _resulting_ (Untitled) page, the Scripts tab shows
the following error:
>
> "Failed to load source for sourceFile URLOnly about:blank script.tags( )"
>
> Any ideas?
>
> Chris
>

keep-alive can be good or bad depending on your situation.  This is the
apache doc about it: http://httpd.apache.org/docs/1.3/keepalive.html

The idea is that you open just a single TCP connection between browser
and server, and make multiple HTTP requests over that connection.  This
is good if you have a lot of resources on a single page that all come
from the same server.

Now the caveats.

1. I'm not sure if the browser will still make multiple parallel
connections to the server or if it tries to push all requests over the
same connection (you can easily test this though).
2. If you have too many resources, your server process can get tied up
for a long time which means you can handle fewer simultaneous clients.
3. If you have a lot of resources (images, css, js), then you should
really be using sprites and combining css files and js files.

In the end, YMMV with Keep-Alive.  try it, run it through some load
testing and decide if you need it or not.  Another thing you could do is
to offload your static resources to a separate domain (if you can easily
create subdomains, this will work), and set up keepalive only for that
virtual host.


Sometime on Nov 8, G dropped bits saying:

> Hi again,
>
> Interesting development (and solution to the strange login redirect).
>
> It turned out that a plugin (which shall remaion nameless) was causing the
redirection to the login panel.
>
> Stranger still: once the plugin was removed, the TTFB dropped to 1.55 sec, and
the document complete fell to 4sec.
>
> The webpagetest.org Performance Review recommended using 'Keep-Alive' - about
which I know precisely ZERO, although I assume it might have something to do
with keeping open the server connection (thus removing the requirement for page
assets to -reform a server connection).
>
> I've found precious little on teh.Google - and the phrase 'keep-alive' does
not appear in http://developer.yahoo.com/performance/rules.html at all (nor does
the word 'persistent').
>
> Can anyody offer any guidance on how such a thing is implemented? It seems to
be a candidate for either httpd.conf (over which I dont' have any control -
shared hosting) or htaccess.
>
> Cheers
>
>
> GT
>
> --- In exceptional-performance@yahoogroups.com, "GT" <GT@...> wrote:
>>
>> Thanks for your response, Pat.
>>
>> I tried running a test of that sort some days ago, but for some odd reason my
site redirected to a login page.
>>
>> The same thing happens with webpagetest.org - odd, that, since the site is
supposed to be viewable by anyone.
>>
>> (As an aside I hope that doesn't happen to everyone who visits: if I log out
and then navigate to the site with a cleared cache, I get the front page that I
expect.)
>>
>> The 'time to first byte' in the Summary was a stonking 5.3  seconds for the
front page the first time I ran that test: the DNS lookup and connection time
were normal (66 and 88 msec respectively).
>>
>> There are some odd things that happen in the 'detailed' pane in the request
trace: (the URL sought is http://www.marketmentat.com )
>>
>> (1) http://www.marketmentat.com - TTFB 2.02sec
>> (2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
>> (3) [login redirect URL] - offset 4.77s TTFB 5.01
>>
>> If I use http://www.marketmentat.com/ (add trailing slash), it becomes
>>
>> (1) http://www.marketmentat.com/ - TTFB 1.19sec
>> (2) login redirect URL - offset 1.37sec, TTFB 1.20sec
>>
>> I find it staggering that the trailing slash makes such a difference.
>>
>> Job 1 is obviously figuring out why the redirect to the login page occurs.
The 'start offset' of the login page is 4.77sec, so I am thinking that if the
redirect was not in force there would be at least some savings.
>>
>> Cheerio
>>
>>
>> GT
>>
>> --- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@>
wrote:
>>>
>>> I did a bulk analysis a few months ago at all of the tests that had been
>>> submitted to WebPagetest <http://www.webpagetest.org/>  here (24k unique
>>> urls): http://www.webpagetest.org/forums/showthread.php?tid=22
>>>
>>>
>>>
>>> One of the stats I looked at was the Time To First Byte (which as I measure
>>> it includes the DNS, initial socket connect and time for the server to send
>>> the first bit of response  back).
>>>
>>>
>>>
>>> The knee in the curve for TTFB is around 2 seconds with 90% of the sites
>>> coming back faster than that (76% of the sites came back under 500ms) - and
>>> this is including 50ms * 3 of Round-Trip-Time for last-mile network latency.
>>> 3 seconds would be around the 95th percentile, 4 at the 96th percentile and
>>> 9 seconds at the 98th percentile (with higher being worse in this case - 98%
>>> of sites tested were faster).
>>>
>>>
>>>
>>> If you run a test on WebPagetest <http://www.webpagetest.org/>  you can
>>> pretty much figure out what the RTT to the server is by looking at the time
>>> for the socket connect on the base page (this would be the PING time).  The
>>> VAST majority of your time is going to be coming from server resources -
>>> unless your hosting company is in the moon J
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -Pat
>>>
>>>
>>>
>>> From: exceptional-performance@yahoogroups.com
>>> [mailto:exceptional-performance@yahoogroups.com] On Behalf Of GT
>>> Sent: Thursday, November 05, 2009 4:56 PM
>>> To: exceptional-performance@yahoogroups.com
>>> Subject: [exceptional-performance] 'Waiting for server response' and flush()
>>>
>>>
>>>
>>>
>>>
>>> Hey y'all
>>>
>>> My site's performance has benefited greatly from YSlow and the various
>>> hints: the next step for me is to try to combine images into sprites... I
>>> was staggered to see how much slack there is in loading the underlying
>>> images that are so fundamental to even the most basic website.
>>>
>>> FireBug/YSlow has also shown me is that not enough is made of the benefits
>>> of a PHP 'flush()' directive at the first sensible opportunity; this is easy
>>> to overlook but has significant benefits.
>>>
>>> One thing that I have noticed though, is that I get significant (>3 or 4
>>> seconds - and up to NINE seconds) "Waiting for server response" on the
>>> initial GET of any page on my server.
>>>
>>> The issue is (as I would expect) not as bad on my local clone of the site,
>>> but it's still upwards of 2-3sec and it easily the largest component in the
>>> delay between hitting the URL and getting a 'navigable' page.
>>>
>>> It would be terrific if someone could prepare a little guide as to what to
>>> expect as a 'normal' server response time - ow it relates (if at all) to
>>> PING and TRACERT times and how much is determined by server resources. After
>>> all, I can run a debugger and see how long the server takes to 'sticky-tape'
>>> the actual page together... and it's nowhere NEAR 3 seconds (it's more like
>>> 0.3) - so it's not an issue of the server making the browser wait 7 seconds
>>> while it preps the page.
>>>
>>> I tried using teh.Google (gasp!) to get some answers, but no joy.
>>>
>>> Cheerio
>>>
>>> GT
>>> Australia
>>>
>>
>
>
>
>
> ------------------------------------
>
>

Hi,

the JSLint tool in YSlow doesn't work for me. It just displays a (Untitled) page
with the content "undefined".

- Tried it on several (quite different) pages.
- Tried it on Mac (Firefox 3.5.5, Firebug 1.4.3) and Windows (Firefox 3.5.3,
Firebug 1.4.5).

Maybe it has something to do with this error:
When I open Firebug on the _resulting_ (Untitled) page, the Scripts tab shows
the following error:

"Failed to load source for sourceFile URLOnly about:blank script.tags( )"

Any ideas?

Chris

Hi again,

Interesting development (and solution to the strange login redirect).

It turned out that a plugin (which shall remaion nameless) was causing the
redirection to the login panel.

Stranger still: once the plugin was removed, the TTFB dropped to 1.55 sec, and
the document complete fell to 4sec.

The webpagetest.org Performance Review recommended using 'Keep-Alive' - about
which I know precisely ZERO, although I assume it might have something to do
with keeping open the server connection (thus removing the requirement for page
assets to -reform a server connection).

I've found precious little on teh.Google - and the phrase 'keep-alive' does not
appear in http://developer.yahoo.com/performance/rules.html at all (nor does the
word 'persistent').

Can anyody offer any guidance on how such a thing is implemented? It seems to be
a candidate for either httpd.conf (over which I dont' have any control - shared
hosting) or htaccess.

Cheers


GT

--- In exceptional-performance@yahoogroups.com, "GT" <GT@...> wrote:
>
> Thanks for your response, Pat.
>
> I tried running a test of that sort some days ago, but for some odd reason my
site redirected to a login page.
>
> The same thing happens with webpagetest.org - odd, that, since the site is
supposed to be viewable by anyone.
>
> (As an aside I hope that doesn't happen to everyone who visits: if I log out
and then navigate to the site with a cleared cache, I get the front page that I
expect.)
>
> The 'time to first byte' in the Summary was a stonking 5.3  seconds for the
front page the first time I ran that test: the DNS lookup and connection time
were normal (66 and 88 msec respectively).
>
> There are some odd things that happen in the 'detailed' pane in the request
trace: (the URL sought is http://www.marketmentat.com )
>
> (1) http://www.marketmentat.com - TTFB 2.02sec
> (2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
> (3) [login redirect URL] - offset 4.77s TTFB 5.01
>
> If I use http://www.marketmentat.com/ (add trailing slash), it becomes
>
> (1) http://www.marketmentat.com/ - TTFB 1.19sec
> (2) login redirect URL - offset 1.37sec, TTFB 1.20sec
>
> I find it staggering that the trailing slash makes such a difference.
>
> Job 1 is obviously figuring out why the redirect to the login page occurs. The
'start offset' of the login page is 4.77sec, so I am thinking that if the
redirect was not in force there would be at least some savings.
>
> Cheerio
>
>
> GT
>
> --- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@>
wrote:
> >
> > I did a bulk analysis a few months ago at all of the tests that had been
> > submitted to WebPagetest <http://www.webpagetest.org/>  here (24k unique
> > urls): http://www.webpagetest.org/forums/showthread.php?tid=22
> >
> >
> >
> > One of the stats I looked at was the Time To First Byte (which as I measure
> > it includes the DNS, initial socket connect and time for the server to send
> > the first bit of response  back).
> >
> >
> >
> > The knee in the curve for TTFB is around 2 seconds with 90% of the sites
> > coming back faster than that (76% of the sites came back under 500ms) - and
> > this is including 50ms * 3 of Round-Trip-Time for last-mile network latency.
> > 3 seconds would be around the 95th percentile, 4 at the 96th percentile and
> > 9 seconds at the 98th percentile (with higher being worse in this case - 98%
> > of sites tested were faster).
> >
> >
> >
> > If you run a test on WebPagetest <http://www.webpagetest.org/>  you can
> > pretty much figure out what the RTT to the server is by looking at the time
> > for the socket connect on the base page (this would be the PING time).  The
> > VAST majority of your time is going to be coming from server resources -
> > unless your hosting company is in the moon J
> >
> >
> >
> > Thanks,
> >
> >
> >
> > -Pat
> >
> >
> >
> > From: exceptional-performance@yahoogroups.com
> > [mailto:exceptional-performance@yahoogroups.com] On Behalf Of GT
> > Sent: Thursday, November 05, 2009 4:56 PM
> > To: exceptional-performance@yahoogroups.com
> > Subject: [exceptional-performance] 'Waiting for server response' and flush()
> >
> >
> >
> >
> >
> > Hey y'all
> >
> > My site's performance has benefited greatly from YSlow and the various
> > hints: the next step for me is to try to combine images into sprites... I
> > was staggered to see how much slack there is in loading the underlying
> > images that are so fundamental to even the most basic website.
> >
> > FireBug/YSlow has also shown me is that not enough is made of the benefits
> > of a PHP 'flush()' directive at the first sensible opportunity; this is easy
> > to overlook but has significant benefits.
> >
> > One thing that I have noticed though, is that I get significant (>3 or 4
> > seconds - and up to NINE seconds) "Waiting for server response" on the
> > initial GET of any page on my server.
> >
> > The issue is (as I would expect) not as bad on my local clone of the site,
> > but it's still upwards of 2-3sec and it easily the largest component in the
> > delay between hitting the URL and getting a 'navigable' page.
> >
> > It would be terrific if someone could prepare a little guide as to what to
> > expect as a 'normal' server response time - ow it relates (if at all) to
> > PING and TRACERT times and how much is determined by server resources. After
> > all, I can run a debugger and see how long the server takes to 'sticky-tape'
> > the actual page together... and it's nowhere NEAR 3 seconds (it's more like
> > 0.3) - so it's not an issue of the server making the browser wait 7 seconds
> > while it preps the page.
> >
> > I tried using teh.Google (gasp!) to get some answers, but no joy.
> >
> > Cheerio
> >
> > GT
> > Australia
> >
>

Thanks for your response, Pat.

I tried running a test of that sort some days ago, but for some odd reason my
site redirected to a login page.

The same thing happens with webpagetest.org - odd, that, since the site is
supposed to be viewable by anyone.

(As an aside I hope that doesn't happen to everyone who visits: if I log out and
then navigate to the site with a cleared cache, I get the front page that I
expect.)

The 'time to first byte' in the Summary was a stonking 5.3  seconds for the
front page the first time I ran that test: the DNS lookup and connection time
were normal (66 and 88 msec respectively).

There are some odd things that happen in the 'detailed' pane in the request
trace: (the URL sought is http://www.marketmentat.com )

(1) http://www.marketmentat.com - TTFB 2.02sec
(2) http://www.marketmentat.com/ - offset 2.34sec, TTFB 2.27sec
(3) [login redirect URL] - offset 4.77s TTFB 5.01

If I use http://www.marketmentat.com/ (add trailing slash), it becomes

(1) http://www.marketmentat.com/ - TTFB 1.19sec
(2) login redirect URL - offset 1.37sec, TTFB 1.20sec

I find it staggering that the trailing slash makes such a difference.

Job 1 is obviously figuring out why the redirect to the login page occurs. The
'start offset' of the login page is 4.77sec, so I am thinking that if the
redirect was not in force there would be at least some savings.

Cheerio


GT

--- In exceptional-performance@yahoogroups.com, "Patrick Meenan" <PatMeenan@...>
wrote:
>
> I did a bulk analysis a few months ago at all of the tests that had been
> submitted to WebPagetest <http://www.webpagetest.org/>  here (24k unique
> urls): http://www.webpagetest.org/forums/showthread.php?tid=22
>
>
>
> One of the stats I looked at was the Time To First Byte (which as I measure
> it includes the DNS, initial socket connect and time for the server to send
> the first bit of response  back).
>
>
>
> The knee in the curve for TTFB is around 2 seconds with 90% of the sites
> coming back faster than that (76% of the sites came back under 500ms) - and
> this is including 50ms * 3 of Round-Trip-Time for last-mile network latency.
> 3 seconds would be around the 95th percentile, 4 at the 96th percentile and
> 9 seconds at the 98th percentile (with higher being worse in this case - 98%
> of sites tested were faster).
>
>
>
> If you run a test on WebPagetest <http://www.webpagetest.org/>  you can
> pretty much figure out what the RTT to the server is by looking at the time
> for the socket connect on the base page (this would be the PING time).  The
> VAST majority of your time is going to be coming from server resources -
> unless your hosting company is in the moon J
>
>
>
> Thanks,
>
>
>
> -Pat
>
>
>
> From: exceptional-performance@yahoogroups.com
> [mailto:exceptional-performance@yahoogroups.com] On Behalf Of GT
> Sent: Thursday, November 05, 2009 4:56 PM
> To: exceptional-performance@yahoogroups.com
> Subject: [exceptional-performance] 'Waiting for server response' and flush()
>
>
>
>
>
> Hey y'all
>
> My site's performance has benefited greatly from YSlow and the various
> hints: the next step for me is to try to combine images into sprites... I
> was staggered to see how much slack there is in loading the underlying
> images that are so fundamental to even the most basic website.
>
> FireBug/YSlow has also shown me is that not enough is made of the benefits
> of a PHP 'flush()' directive at the first sensible opportunity; this is easy
> to overlook but has significant benefits.
>
> One thing that I have noticed though, is that I get significant (>3 or 4
> seconds - and up to NINE seconds) "Waiting for server response" on the
> initial GET of any page on my server.
>
> The issue is (as I would expect) not as bad on my local clone of the site,
> but it's still upwards of 2-3sec and it easily the largest component in the
> delay between hitting the URL and getting a 'navigable' page.
>
> It would be terrific if someone could prepare a little guide as to what to
> expect as a 'normal' server response time - ow it relates (if at all) to
> PING and TRACERT times and how much is determined by server resources. After
> all, I can run a debugger and see how long the server takes to 'sticky-tape'
> the actual page together... and it's nowhere NEAR 3 seconds (it's more like
> 0.3) - so it's not an issue of the server making the browser wait 7 seconds
> while it preps the page.
>
> I tried using teh.Google (gasp!) to get some answers, but no joy.
>
> Cheerio
>
> GT
> Australia
>