SPDY vs RTT

‹prev | My Chain | next›

Last night I got a simplistic website + CDN up and running in VMs. Nothing too fancy -- a single web page served across a 100ms RTT connection and a 30ms RTT CDN. There were only a dozen or so resources served from the CDN, which is a far cry from the typical 53(!) served on most websites. Still, it ought to serve as a useful point of discussion.

In all the web site + CDN completed all data transfer in 670ms.

Tonight, I am going to put a SPDY server on the 100ms RTT web server and serve all of the content from the SPDY server.

I have my express-spdy server laid out thusly:

app.js
views/real.jade
views/layout.jade
views/index.jade
public/images/hello_world.jpg
public/images/11-bang.jpg
public/images/03-l.jpg
public/images/02-l.jpg
public/images/05-space.jpg
public/images/10-d.jpg
public/images/09-l.jpg
public/images/00-h.jpg
public/images/01-e.jpg
public/images/07-o.jpg
public/images/04-o.jpg
public/images/08-r.jpg
public/images/06-w.jpg
public/javascripts/jquery-1.6.2.min.js
public/stylesheets/style.css

It's not a 100% fair comparison with the static since since we're compiling Jade templates, but hopefully it is not too far off.

I set my delay of 100ms and clear any routing caches that might be about:

➜  ~  sudo tc qdisc add dev lo root netem delay 50ms
[sudo] password for cstrom: 
➜  ~  ping localhost
PING localhost.localdomain (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=1 ttl=64 time=100 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=2 ttl=64 time=100 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=3 ttl=64 time=100 ms
64 bytes from localhost.localdomain (127.0.0.1): icmp_req=4 ttl=64 time=100 ms
^C
--- localhost.localdomain ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 100.091/100.128/100.156/0.225 ms
➜  ~  sudo ip route flush cache

When I load the site up, I find:



Bleh. That's not all that speedy.


1.11s (onload: 1.12s, DOMContentLoaded: 685ms).


That is all worse than just using the vanilla HTTP. The initial SSL negotiation makes the web page load slower than vanilla HTTP and it is all downhill from there.

My takeaways from this? There is no way to overcome poor RTT. If it takes 50ms for a request to hit the server and another 50ms for the response to reach the browser, there is nothing that can change that. Not even SPDY.


But, as readers of the SPDY Book already know, this is not the end of the story. I will pick back up with that tomorrow.


Day #81