Today I take a break from bashing my head against pipelining to take a closer look at Speed Tracer. Speed Tracer is a nice little Chrome extension for visualizing rendering and networking events.
For the SPDY Book, I have a little test page that includes CSS, javascript and several images. When I examine the page with Speed Tracer, I see the following in the "Network" tab:
More than one thing strikes me as odd with this trace. Given my understanding of browsers and their 6 tubes, I would expect 6 requests to start as soon as the page was parsed. But there are only two: for the CSS and Javascript on the page. I suppose that I can convince myself that Chrome requests resources inside the
<head> section of a web page first. Maybe that makes sense.But what happens next is even stranger. Chrome sends out 10 requests at the same time. As far as I know, Chrome does not use pipelining and has a maximum of 6 interweb tubes on which to request concurrent resources. But, according to Speed Tracer, Chrome is requesting 10+ images at the same time.
Stranger still, the first 2 images come back relatively quickly while the others take progressively longer:
The light blue on the left side of the request is how long it takes the request to be sent and the time waiting for the response to start coming back. All requests in this diagram are at least 100ms because there is a 100ms round trip time between the client and server. The response itself takes a while because the image is largish (10kb) and the interweb tube being used is not warm.
After those first two requests then the next 6 requests come back a while later. All 6 return at nearly the same time. Six. As in the number of tubes being used by modern browsers.
To figure this out, I drop down to Wireshark to have a look at the packets. Looking at the end of the response for the Javascript and CSS, I find:
The next 6 images are being requested at almost the same time. But wait a second... Speed Tracer told me that all 10+ images were being requested at the same time. Wireshark, which I definitely believe, is telling me that only 6 images are requested and then nothing happens other than data responses.
What the hell, Speed Tracer… What the hell?
Scrolling down a bit, once the first 6 images are sent back, only then does Chrome start the next requests:
So Chrome is definitely not pipelining. All images are requested on separated interweb tubes. There are six tubes. Just like I expected.
So Speed Tracer is lying. Great.
Even better, I notice the following request going out before the initial request for the web resource:
What the heck is a
/symbolmanifest? I certainly did not put that in my sample application. Ugh. It turns out to be a Speed Tracer mechanism for de-obfuscating Javascript. I suppose that might help Speed Tracer to analyze some of what the Javascript is doing on a page, but... it is loading before the rest of the application. After that response, the actual page is loaded—on the same tube. The tube is getting pre-warmed by a request that is hidden from the user by a tool that is supposed to help analyze, among other things, network issues.
Bah! Bad form Speed Tracer. Bad form.
I'll open an issue on the Speed Trace tracker about this. In the meantime, it seems I need another tool to help with SPDY Book.
Ugh.
Day #74
SpeedTracer monitors network activity from the "renderer's perspective". The browser knows it needs to get the resource, and it get handed over to the browser process, and thrown into the network queue. The 6-connection-per-domain throttle kicks in and the request waits for a long time before it actually hits the network.
ReplyDeleteThis is the sad thing about browsers (without SPDY). They know they need to fetch resources, but they self throttle due to poor network utilization.
Maybe someone should create a protocol for that.
Ah. "Render's perspective". I _suppose_ I can accept that :)
ReplyDeleteStill, it really makes it seem as though the website is being unresponsive, not something internal to the browser. Maybe a third color to indicate in the browser's internal network queue would help.
"Maybe someone should create a protocol for that" -- hahaha :)