WebPagetest Forums
How to solve "0 ms (Request Canceled)" problem? - Printable Version

+- WebPagetest Forums (https://www.webpagetest.org/forums)
+-- Forum: Web Performance (/forumdisplay.php?fid=3)
+--- Forum: Optimization Discussions (/forumdisplay.php?fid=5)
+--- Thread: How to solve "0 ms (Request Canceled)" problem? (/showthread.php?tid=202)

Pages: 1 2 3

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-03-2010 06:09 PM

I was able to reduce image sizes further by 14KB. Total size 104KB. Results (via Dulles, VA USA): Again and again -- IE8 is slower. Are you sure that both "boxes" are identical? Is it possible that shaping is more aggressive on IE8 box?

Additionally, I have created inline CSS /w post load (after onload event). IE7 disappoints, while IE8 shows some improvements (speed wise), but still not fast enough. Results (via Dulles, VA USA): As you can see, layout.png (50KB) starts downloading as fast as possible (except, it requires to establish a new connection 2nd request), but still is not able to finish faster (it remains as last item who triggers document complete event). TCP slow start, or what? Anyway, I think that results are acceptable, so "embed CSS" project will be frozen for some time.

P.S. 0ms issue still in place.
P.S.S. All times are based on 10 runs. Best time is taken.

RE: How to solve "0 ms (Request Canceled)" problem? - pmeenan - 05-03-2010 10:38 PM

Yep, I'm positive that both boxes are identical and the traffic shaping is actually done at the router that is shared between the boxes so I'm positive about that as well.

I am experimenting with running the tests in a VM on much faster hardware but in that case IE7 and IE8 would be on the same box. Here are the results from that setup:

IE7 - 1.001s
IE8 - 1.221s

I'd actually throw away the first IE7 run because it took the hit for caching the DNS results. Looks like you broke the 1 second mark on the faster hardware with times ~ 0.983s

I think IE8's increased number of parallel connections is actually working against it for a site like yours where you have so few requests.


[Image: waterfall.png?test=100503_27381123ba33cd...;requests=]


[Image: waterfall.png?test=100503_15a788c0f07d01...;requests=]

Looks like the 0ms request has followed your site to the VM's as well Dodgy

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-04-2010 05:31 PM

Thanks for all the info...

Meanwhile, I worked on response headers. Most significant change I have made is that I added Content-Type: text/html; charset=UTF-8 right in response header for all base files. That allowed me to remove <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"> from each and every base file (+/- 1,000 pages) head section. Technically, I have saved just a few bytes, but... same total size 104KB. Results (via Dulles, VA USA): Not sure why (can speculate, that providing browser with charset early allows to render page faster Idea true/false?), but results are best ever.

I agree, IE8 somehow messes up with many connections. Hope, in IE9 they will figure out how much new connections they have to establish (connection:total_request wise).

(05-03-2010 10:38 PM)pmeenan Wrote:  Looks like the 0ms request has followed your site to the VM's as well Dodgy
gigi Wink

Currently working in deep pages. Thinking about on how to reduce root even further -- down to 99KB Cool

P.S. English is my 3rd language... after re-reading some of my posts... I messed... plurals, tense... blah Blush

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-04-2010 07:34 PM

(05-04-2010 05:31 PM)laboot Wrote:  I added Content-Type: text/html; charset=UTF-8 right in response header...

Side effects may occur... w3.org does not like this approach.

Page still validates, but... Result: Passed, 1 warning(s)

And explanation is stupid... No Character encoding declared at document level. More / full bla bla...

Quote:No character encoding information was found within the document, either in an HTML meta element or an XML declaration. It is often recommended to declare the character encoding in the document itself, especially if there is a chance that the document will be read from or saved to disk, CD, etc.

If they say "It is often recommended", then why this is warning? Stupid semantics -- they should add 3rd level of feedback, e.g. Errors / Warnings / Info (aka recommendations).

Thanks w3 for ruining my day!

P.S. Till today all my pages (html/css/xml/pad/etc) validated without any single error or warning. Till today...

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-05-2010 04:48 PM

Here we go - managed to reduce page size to 91KB. The same content, the same images, just a lot smaller size. Results (via Dulles, VA USA): I paid special attention to network packets (MTU wise), used wireshark to watch closely on how my network packets flow. As a result, all 4 images (via IMG tag) uses packet "payload" at full efficiency -- last packet is almost fully loaded (just +/- 100 bytes remains free). For example, both "virtual boxes".png files uses just 2 network packets each.

No one on entire internet does not speak on this. Googled everything, but info is just some bits there and there. So, to all who hear my words, I say this -- "Most common MTU is 1500 (or 1514), which leaves room for actual 1460 bytes. And first packet loses additional +/-380 bytes due response headers." From this point on, it is easy to create an excel sheet with necessary data... Also, based on file type, response headers will vary by, generally +/- 50 bytes.

Idea Perhaps, you can implement some stats on how many network packets each request taken? Especially for smaller files (let's say up to 10-15KB) where every unnecessary packet causes noticeable penalty. Community will appreciate that. Or this is overkill?

Ok, back to work. Work harder Smile

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-05-2010 07:02 PM

More about network packets. Let's take this test run, namely request #8.

Response header (326 bytes + 4 bytes (2 CRs). Total 330 bytes):
Quote:HTTP/1.1 200 OK
Date: Wed, 05 May 2010 06:45:14 GMT
Server: Apache/2.2.15
Last-Modified: Tue, 04 May 2010 09:49:42 GMT
Accept-Ranges: bytes
Content-Length: 2498
Cache-Control: public, max-age=2592000
Expires: Fri, 04 Jun 2010 06:45:14 GMT
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: image/jpeg

As we can see, image is 2498 bytes long. So how it fits into packets? If we want to squeeze it into 2 packets, total image size should be smaller than:
payload * packetcount - header
We translate this to bytes, and get:
1460 * 2 - 330 = 2590
Mathematicians says that 2498 is smaller than 2590. Tadaaa. We win!

Also, to reduce response header size, someone may consider to remove Last-Modified header line (e.g. Last-Modified: Tue, 04 May 2010 09:49:42 GMT). But, after image expires (1 month: Expires: Fri, 04 Jun 2010 06:45:14 GMT), there will be penalty in form of new image download (200), instead of not modified (304). Think.

Back to work Smile

RE: How to solve "0 ms (Request Canceled)" problem? - pmeenan - 05-05-2010 10:29 PM

You have definitely graduated to the next level of performance optimization :-) (Just be careful to not over-optimize beyond where you see value in return).

FWIW, if you look in the data table there is a "Bytes In" value that will tell you the number of bytes for the response including the headers (but not including the TCP overhead. You may want to target a 1492 MTU (granted, just 8 bytes different) because DSL (PPPoE specifically) has 8 bytes of overhead on the wire.

Where you'll really see the benefit if you're going to start looking at packet-level data is in the base page or the initial request on any new connection. With TCP slow start you can usually get 2 packets out before having to wait for another round trip so for the base page make sure as much of your external references/head makes it into the first 2 packets as possible.

You'll also want to see if you can flush the document early. Not sure what technology is serving your pages but if you can force the head of the document out before making any database or back-end calls you will speed up the page getting to the users. You're basically looking to reduce the first byte time on the base page as much as possible (the fastest it can get would be to match the socket connect time - so the green and orange bars would be the same size).

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-06-2010 05:10 PM

pmeenan Wrote:... to the next level of performance optimization...

The same size, the same images. All the same. Except, I have paid special attention on how to use connections wisely. And the results are (via Dulles, VA USA): Goal is reached! Done me is with this Smile

Idea You have to charge (at least $10 on a monthly basis?) for a premium services, such as connection view, record video / film strip view / number of runs >1, etc. Of course, basic features remains free. No doubt, you have the best tool on the market! All the other stuff I have googled for, is a total crap compared to this tool. Heart

P.S. You know in advance, you have at least one customer (subscriber). Guaranteed!

Also, just curious - could you please run this test on your fast VM machine? Please Smile

RE: How to solve "0 ms (Request Canceled)" problem? - pmeenan - 05-06-2010 10:26 PM

As long as you (or anyone else using it) understands that the "hidden" locations are still experimental or not yet deployed, feel free to use them: http://www.webpagetest.org/test?hidden=1

Right now the VM's are the only hidden location (last location - Dulles) and they allow for full customizing of the bandwidth (as well as the standard pre-defined profiles). I will sometimes hide an existing location if it is not responding until we get it back online and new locations will be hidden while they get installed so there's generally no guarantees there :-)

On the subscription side, my goal has always been to have the site be as close to revenue-neutral as possible. The ads offset the hosting costs and some of the costs for operating the Dulles location and the other locations are being supported by great partners. AOL has essentially been funding the development costs by open sourcing what was an internal tool and allowing me to continue to enhance it (looking to get more corporate branding on the site but historically it wasn't worth the corporate hurdles). At this point I'd like to see it work to help build up the general community around performance and as Google likes to say "Help make the web a faster place".

Really nice work on the optimizations btw - you may have a second calling as a performance geek :-)

RE: How to solve "0 ms (Request Canceled)" problem? - laboot - 05-16-2010 10:09 PM

More work has been done.
The problem is that Compress Images score is C. The idea is that 4 images are loaded at the very end (requests 9-12), after Document complete, after javascript, after everything else. Javascript uses some voodoo and replaces low quality images with HD images.

Idea Perhaps, if images are served from hd subdomain, such as hd.example.com, penalty is not applied? Or issue warning, but do not affect overal image score in this case? Or is there some other way to serve high (best possible) quality images to user without score below A? Huh

Help! Please.

Remember that Google charges for premium services.