SPDY Not As Speedy As Hyped?

Freshly Exhumed writes "Akamai's Guy Podjarny reveals after testing: SPDY is different than HTTP in many ways, but its primary value comes from being able to multiplex many requests/responses from client to server over a single (or few) TCP connections. Previous benchmarks tout great benefits, ranging from making pages load 2x faster to making mobile sites 23% faster using SPDY and HTTPS than over clear HTTP. However, when testing real world sites I did not see any such gains. In fact, my tests showed SPDY is only marginally faster than HTTPS and is slower than HTTP."

Re:Not so fast...YET

[Anonymous Coward]

I came here to say something like "read the article, the guy is from Akamai and would know to only use servers that serve SPDY - such as many of the Google properties". But then, I read the fine article (blog) and realized the guy doesn't know enough to do that and just used "the top 500 sites" - which means a very large chunk of them don't know what SPDY is and he only used it between himself and his proxy. Great test that was. So your point is well taken. Bogus test means bogus results.

Re:Not so fast...YET

[dave420]

And unless that proxy used SPDY to talk to the servers, or had them entirely cached, that means nothing.

Re:Single domain?

[Anonymous Coward]

This is not at all true. There were numerous stories about how Google worked with CDNs to ensure compatibility with OpenDNS. Here's one example from last year:
http://arstechnica.com/tech-policy/2011/08/opendns-and-google-working-with-cdns-on-dns-speedup/ [arstechnica.com]

As for SSL False Start, the problem was a handful of SSL terminators that violated the spec. Unfortunately, most of the manufacturers of those devices showed no interest in making a trivial fix to their implementations, and the few that did make the fix didn't bother to deploy it to existing customers. So, everyone had to suffer because 0.5% of SSL servers were broken:
http://arstechnica.com/business/2012/04/google-abandons-noble-experiment-to-make-ssl-less-painful/ [arstechnica.com]

Re:Not so fast...YET

[Anonymous Coward]

The reason SPDY doesn't help much is that your average web site now requires connections to a dozen other domains (each with only one or two requests), meaning that consolidating the requests to the main domain into a single connection just isn't that beneficial.

dom

The problem with the test ...

[sharepass11]

IMHO, there is a huge issue with this test. On one hand its author claims : "However, when testing real world sites I did not see any such gains. In fact, my tests showed SPDY is only marginally faster than HTTPS and is slower than HTTP." But on the other hand at bottom lines it states : "This means SPDY doesn’t make a material difference for page load times, and more specifically does not offset the price of switching to SSL." SSL ? Wait a minute doc ... there is something wrong with the flux capacitor ! In fact to "SPDY"-fy the sites, the guy clarifies the technique he used : "For a proxy, I used the Cotendo CDN (recently acquired by Akamai). Cotendo was one of the early adopters of SPDY, has production-grade SPDY support and high performance servers. Cotendo was used in three modes – HTTP, HTTPS and SPDY (meaning HTTPS+SPDY)." You get it ? No, not the advertisement for cotendo ... ... He did not tested SPDY at all but tested TLS+SPDY !!! WTF ?!? Either the guy should upgrade all his article replacing SPDY with TLS+SPDY or he should trash it and make another one only with SPDY. Then we will start to discuss about some of his strange benchmark decision... Sad that such a odd article get so much press here :(

Re:What is the big deal with SPDY?

[rekoil]

1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.

2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.

3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.

4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.

5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).

But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.

The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).

Re:The problem with the test ...

[rekoil]

SPDY as implemented requires SSL, since the protocol capability is negotiated by a TLS extension on port 443. There's no spec for negotiating SPDY on a standard HTTP port - it would only work if the capability was assumed on both sides before the connection (for example, URLs that start with spdy:// instead of http:/// [http] which connects to a different TCP port on the server).