SPDY vs SSL

‹prev | My Chain | next›

Yesterday, I ran a moderately simple SPDY web site over a simulated 100ms round-trip connection.

Today, I would like to see if I can cut down on that time some by using SPDY server push. By pushing resources directly into the browser cache, I should be able to overcome at least some of the RTT that is in place.

But when I first load up the page, pushing all static resources into cache, I find:



Bah! 2+ seconds?! That's terrible. Far worse than the simulated CDN over vanilla HTTP. What gives?

To figure out the delay, I check things out in the SPDY tab of Chrome's about:net-internals:

t=1311473528051 [st=   0]     SPDY_SESSION_SYN_STREAM  
                              --> flags = 1
                              --> accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
                                  accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
                                  accept-encoding: gzip,deflate,sdch
                                  accept-language: en-US,en;q=0.8
                                  host: spdy.local:3000
                                  method: GET
                                  referer: https://spdy.local:3000/
                                  scheme: https
                                  url: /real
                                  user-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.825.0 Safari/535.1
                                  version: HTTP/1.1
                              --> id = 1

Off to a reasonable start. Next, I reach the point that server push should go out:

t=1311473528260 [st= 209]     SPDY_SESSION_PUSHED_SYN_STREAM  
                              --> associated_stream = 1
                              --> flags = 2
                              --> status: 200
                                  url: https://jaynestown.local:3000/stylesheets/style.css
                                  version: http/1.1
                              --> id = 2

OK. That looks good. Unfortunately, Chrome does not agree. It sends back a reset stream on my server push:

t=1311473528260 [st= 209]     SPDY_SESSION_SEND_RST_STREAM  
                              --> status = 3
                              --> stream_id = 2

Hunh?

Oh! This is not longer my local machine (jaynestown). This is a new spdy.local VM on which I am testing RTT, so I need to update the hostname accordingly:

function local_path_and_url(relative_path) {
  return [
    "public/" + relative_path,
    "https://spdy.local:3000/" + relative_path
  ];
}

Now, when I run it, I get... only somewhat better results:



Hrm... That initial connection is a lot longer than last night (only took ~200ms for a SPDY/SSL connection last night). Tonight, the browser is spending a lot of time during SSL negotiation:



Bah. This is one of the hazzards of small bites of research. I am doing something very different tonight than I did last night. I am going to need to go back and redo last night's work to make sure I did not skip a step when simulating SPDY over a high latency connection.

As for tonight's results, the remainder of the resources load in less than 600ms. I am still looking at 1.3 seconds total—a far cry from the 700ms download time of the simulated CDN from the other night. I can certainly eek out a bit more performance by gzip'ing the jQuery library, but still, if the initial SSL negotiation takes more almost as much time as the HTTP + CDN site, SPDY isn't much of a match.

I should note that SPDY is not supposed to mean and end for the CDN, but it would be pretty cool to get response times down to near CDN levels.

Ugh. Mostly I miss the Speed Tracer extension for Chrome. It seemed to have a better SPDY sense (I've been wait a long time to use that one) than does network manager. I'd really like to get a definitive handle on SPDY and RTT, but it may have to wait until I regain the use of Speed Tracer (it starts locked with Chrome 14.0.825.0 dev). Dang it.


Day #82