Friday, July 22, 2011

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

2 comments:

  1. CDNs are absolutely great for performance. The key is to get CDNs to support SPDY too.

    Cotendo has announced that they are going to support it, and I think they might even have it available now.

    ReplyDelete
  2. Agreed. I was mostly hoping to get somewhat close to HTTP + CDN level peformance -- even with relatively high latency connections. Probably not do-able, but I'd like to see how close I can get it.

    It would definitely be cool if CDNs would start to support SPDY.

    ReplyDelete