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
>