Tuesday, May 15, 2012

Timing Node-Spdy Implementations

‹prev | My Chain | next›

There seems to be something off with the timing in the spdy-v3 branch of node-spdy. As a baseline, I am going to use Speed Tracer to time vanilla SSL, spdy/2 and the new spdy/3 branches.

To switch between branches, I will simply remove the appropriate entries from the supported NPN protocols in node-spdy's server:
  function Server(options, requestListener) {
    // ...
    options.NPNProtocols = ['spdy/3', 'spdy/2', 'http/1.1', 'http/1.0'];
    // ...
I have something of a love-hate relationship with Speed Tracer. On the one hand it's pretty, contains tons of useful data, and works with SPDY. On the other hand, something always seems to be broken just a bit. Today, I have difficulty getting Speed Tracer to start when the page load starts. I end up needing to load the page, clear the cache, then reload to see anything in Speed Tracer.

The results look something like:

Even with a rather laborious workaround, the start time for the graph is not zero. Speed Tracer seems to recognize this as it shifts the graph to the first request, but the actual start time is somewhere between 0 and 5 seconds. So a little arithmetic is in order as well.

What I find after trying Speed Tracer against SSL, spdy/2 and spdy/3 is that vanilla SSL is the fastest (times in ms):

ProtocolStartDOM LoadEndDuration
ssl 1564 1687 2460 896
spdy/2 1501 1651 2440 939
spdy/3 1120 1308 2260 1140

I am actually not too fussed about SSL being faster than spdy/2. It is only slightly faster and well within the margin of error for my test. I am very concerned about spdy/3 being so much slower. There really does seem to be something wrong here.

Another reason that I am unconcerned about vanilla SSL seemingly besting spdy/2 is that I am running on the loopback interface (lo / localhost). This is a contrived example with no round trip time and so, not at all indicative of real world conditions.

So I add a RTT of 50ms to lo:
sudo tc qdisc add dev lo root netem delay 50ms
Now, when I retry my experiment, spdy/2 handily wins:

ProtocolStartDOM LoadEndDuration
ssl 2210 2780 4400 2190
spdy/2 1514 1851 2690 1176
spdy/3 1921 2270 4830 2909

But spdy/3 still trails both. So, as I suspected from what I saw in Firefox earlier, I need to investigate performance in the spdy-v3 branch of node-spdy.


Day #387

No comments:

Post a Comment