I now have a working implementation of SPDY version 3 in node-spdy. It works with Chrome, spdylay and even Firefox sandbox builds. It works, but it is dog slow. Slower than spdy/2 and even slower than vanilla SSL.
So, in the spirit of first get it working, then do it right, then optimize, well... tonight I skip ahead to optimization—at least of the network.
There is no sense in optimizing for the loopback interface—I would be doing little more than optimizing socket writes. So I start tonight by adding a round trip time (RTT) of 100ms to the loopback interface to make things a bit more realistic (the slowness is still apparent):
sudo tc qdisc add dev lo root netem delay 50msFirst up, I try adding timing output to the spdy/3 flow control in node.js. Specifically, I want to know the times at which node-spdy exhausts the receive window and the times at which Chrome sends back WINDOW_UPDATE to replenish the receive window. It is entirely possible that node-spdy is forced to wait, essentially doing nothing, while Chrome processes already sent data. I doubt it, but it's possible.
It turns out that it is really hard to identify periods of inactivity in node.js, so I give up on that idea quickly.
With that idea down the drain, it is time to break out Wireshark. Specifically, some the node graphing tools that it includes.
For instance, the spdy/3 conversation looks something like:
Compare that with the spdy/2 conversation:
Yikes! The spdy/2 conversation is filling up the TCP/IP receive window much faster. It is also growing the receive window much faster.
I have been speculating that Firefox's SPDY receive window of 256mb is little better than spdy/2, so I try it out:
Indeed it does look a little better, but it is not growing the window nearly as fast as spdy/2.
If this were just Chrome not growing the SPDY receive window, which in turn did not allow the TCP/IP window to grow, then Firefox's curve should be just as steep as spdy/2. Since it is not, there much be something about my node-spdy flow control that is also having a chilling effect on the SPDY conversation. Bummer.
At least I know where to start looking when I pick back up tomorrow.
Day #388
are you by chance aligning your writes differently in a way that could lead to more TCP packets in v3? most TCP implementations measure cwnd in terms of packets not in terms of bytes. (which is kinda crazy, but its a bit stuck like that for legacy reasons). Easy to double check the packet counts in the respective captures.
ReplyDeleteThe same number of bytes split over more tcp packets will mean cwnd takes longer to grow to a point that fills the BDP - a lot longer than the small overhead of more packet headers would make it look like at first.
Looks like it might be nothing more than a capture error: http://japhr.blogspot.com/2012/05/firefox-spdy2-vs-spdy3-in-graphs.html.
DeleteThat's good information to note, but I am fairly certain that node-spdy always sends the same number of packets (the y-axis is sequences), regardless of version. The next night's results suggest that the implementation is more or less solid—but I'll still keep that in mind.