6 ms·

How speedy is SPDY? [pdf]

70 points by ldng 12y ago

Hengjie 12y ago
Trivia: the PDF is in a folder called "protected-files" - LOL
moyix 12y ago
Kudos to them for releasing their data and tools [1]! This is how science should work. [1] http://wprof.cs.washington.edu/spdy/data/ http://wprof.cs.washington.edu/spdy/data/
YZF 12y ago
It's not surprising that introducing high loss through a network emulator results in reduced performance of a single TCP connection vs. multiple connections. That's because there's a relationship between the maximum bandwidth a single TCP connection can carry and the packet loss % due to TCP's congestion avoidance. Introducing "fixed" packet loss through an emulator isn't necessarily a good representation of a real network where packets would be lost due to real congestion (an overflowing queue). Throwing many TCP connections into a congested network can let you get a higher share of that limited pipe though...
- eggnet 12y ago
  Packet loss on wireless networks often have a certain rate of packet loss unrelated to congestion, due to having not a great signal or interference. It's somewhat humorous because wireless networks are one of the main purported benefits of SPDY.
Animats 12y ago
That's a nice study. The main result is that most of the benefit comes from putting everything through one TCP pipe. This, of course, only works if almost everything on a site comes from one host. This is a good assumption for Google sites, which communicate only with the mothership. It's not for most non-Google sites.
- josteink 12y ago
  And for those sites, you can always use HTTP pipelining and avoid the whole SPDY can of worms. Looking at the facts, it seems pretty obvious that whatever theoretical gains you can get in select scenarios with SPDY, this super-minor gain is not worth it compared to the associated complexity cost. Not to mention I don't like the idea of Google now not only running the worlds tracking units, the worlds most popular browser and most popular websites, but now also dictating internet-protocols without taking input from other parties.
  - youngtaff 12y ago
    What's the complexity cost in SPDY or HTTP/2's case? For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.
    - timboslice 12y ago
      >the tradeoff of getting the bundles right, which of course reduces cachability If you are revving your bundles with hashes (main.8a4ce55.js), caching shouldn't be a problem. Not sure what your build process is, but there are plugins to do this on most setups.
      - youngtaff 12y ago
        That's precisely the point revving bundles with hashes is about destroying cachability. When two separate resources together at build time they're being coupled from a caching point of view if one gets changed and the other doesn't they they both have to be re-downloaded because the bundle has changed.
    - josteink 12y ago
      > For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability. And all of this is a build-time problem. If we're going to engineer the HTTP-protocol to solve build-tooling and development related problems, we might as well add JS-linting and minifying to HTTP itself as well. Seriously: This problem is best solved elsewhere.
bsdetector 12y ago
> Most performance impact of SPDY over HTTP comes from its single TCP connection This is not a surprise at all, because Google never tested SPDY against HTTP pipelining. And at least in their mobile test they included the TCP connection time for HTTP but not for SPDY; I suppose their test software just reused the same SPDY connection since the mirrored web pages all were served from the same IP. They compressed sensitive headers with data leading to CRIME attacks. They had a priority inversion causing Google Maps to load much slower through SPDY than HTTP. This new protocol is a complete mess, from beginning to end.
- Lukasa 12y ago
  Leaving aside the technical statements about SPDY, the reality of HTTP pipelining is that no-one uses it. According to Wikipedia, Opera is the only major browser that ships with pipelining enabled. Most intermediaries don't support pipelining either. Pipelining was a well-intentioned feature which didn't solve the core problem: namely, that a big or slow request can block you from doing anything else for a really long time unless you open another TCP connection.
  - mpweiher 12y ago
    > the reality of HTTP pipelining is that no-one uses it. Hmmm, starting to use it seems like less effort than introducing an entirely new protocol. > the core problem: namely, that a big or slow request can block you from doing anything else Why is that the core problem?
    - youngtaff 12y ago
      >> the core problem: namely, that a big or slow request can block you from doing anything else > Why is that the core problem? Head of line blocking leaves the network idle, and one of the key factors to good front end performance is to overcome network latency and start using the network / growing the congestion window as soon as possible.
  - bsdetector 12y ago
    Except that Microsoft tested SPDY against pipelining and found that pipelining was essentially just as good. So we're left with a situation where Google could have used HTTP pipelining over SSL (so there's no buggy proxies interfering, just like what SPDY does) and gotten pretty much all the benefit with no extra complications at all, but instead there's old HTTP and a new, much more complicated protocol. And this "head of line blocking" problem... who said it was a problem, Google? In reality you have 4 or more connections that automatically work like spread spectrum where most resources aren't stuck behind a big or slow request. But even if this was an actual problem, a simple hint in the HTML that the resource might take a while and to put other ones on a separate connection would optionally solve this problem, and with almost no extra complexity.
Mojah 12y ago
Very nice research, kudos to everyone involved. I agree with the conclusions, mostly the very last one. > To improve further, we need to restructure the page load process To fully utilise the potential of HTTP/2, we will have to rethink the way we create and manage websites. I've posted more thoughts on this on my blog; https://ma.ttias.be/architecting-websites-http2-era/ https://ma.ttias.be/architecting-websites-http2-era/

70 points by ldng 12y ago

Trivia: the PDF is in a folder called "protected-files" - LOL

moyix 12y ago

Kudos to them for releasing their data and tools [1]! This is how science should work. [1] http://wprof.cs.washington.edu/spdy/data/ http://wprof.cs.washington.edu/spdy/data/

YZF 12y ago

It's not surprising that introducing high loss through a network emulator results in reduced performance of a single TCP connection vs. multiple connections. That's because there's a relationship between the maximum bandwidth a single TCP connection can carry and the packet loss % due to TCP's congestion avoidance. Introducing "fixed" packet loss through an emulator isn't necessarily a good representation of a real network where packets would be lost due to real congestion (an overflowing queue). Throwing many TCP connections into a congested network can let you get a higher share of that limited pipe though...

eggnet 12y ago
Packet loss on wireless networks often have a certain rate of packet loss unrelated to congestion, due to having not a great signal or interference. It's somewhat humorous because wireless networks are one of the main purported benefits of SPDY.

Animats 12y ago

That's a nice study. The main result is that most of the benefit comes from putting everything through one TCP pipe. This, of course, only works if almost everything on a site comes from one host. This is a good assumption for Google sites, which communicate only with the mothership. It's not for most non-Google sites.

josteink 12y ago
And for those sites, you can always use HTTP pipelining and avoid the whole SPDY can of worms. Looking at the facts, it seems pretty obvious that whatever theoretical gains you can get in select scenarios with SPDY, this super-minor gain is not worth it compared to the associated complexity cost. Not to mention I don't like the idea of Google now not only running the worlds tracking units, the worlds most popular browser and most popular websites, but now also dictating internet-protocols without taking input from other parties.
- youngtaff 12y ago
  What's the complexity cost in SPDY or HTTP/2's case? For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability.
  - timboslice 12y ago
    >the tradeoff of getting the bundles right, which of course reduces cachability If you are revving your bundles with hashes (main.8a4ce55.js), caching shouldn't be a problem. Not sure what your build process is, but there are plugins to do this on most setups.
    - youngtaff 12y ago
      That's precisely the point revving bundles with hashes is about destroying cachability. When two separate resources together at build time they're being coupled from a caching point of view if one gets changed and the other doesn't they they both have to be re-downloaded because the bundle has changed.
  - josteink 12y ago
    > For most optimised HTTP/1.x sites there's already a complexity cost of merging JS files, merging CSS files building sprites - including the tradeoff of getting the bundles right, which of course reduces cachability. And all of this is a build-time problem. If we're going to engineer the HTTP-protocol to solve build-tooling and development related problems, we might as well add JS-linting and minifying to HTTP itself as well. Seriously: This problem is best solved elsewhere.

bsdetector 12y ago

> Most performance impact of SPDY over HTTP comes from its single TCP connection This is not a surprise at all, because Google never tested SPDY against HTTP pipelining. And at least in their mobile test they included the TCP connection time for HTTP but not for SPDY; I suppose their test software just reused the same SPDY connection since the mirrored web pages all were served from the same IP. They compressed sensitive headers with data leading to CRIME attacks. They had a priority inversion causing Google Maps to load much slower through SPDY than HTTP. This new protocol is a complete mess, from beginning to end.

Lukasa 12y ago
Leaving aside the technical statements about SPDY, the reality of HTTP pipelining is that no-one uses it. According to Wikipedia, Opera is the only major browser that ships with pipelining enabled. Most intermediaries don't support pipelining either. Pipelining was a well-intentioned feature which didn't solve the core problem: namely, that a big or slow request can block you from doing anything else for a really long time unless you open another TCP connection.
- mpweiher 12y ago
  > the reality of HTTP pipelining is that no-one uses it. Hmmm, starting to use it seems like less effort than introducing an entirely new protocol. > the core problem: namely, that a big or slow request can block you from doing anything else Why is that the core problem?
  - youngtaff 12y ago
    >> the core problem: namely, that a big or slow request can block you from doing anything else > Why is that the core problem? Head of line blocking leaves the network idle, and one of the key factors to good front end performance is to overcome network latency and start using the network / growing the congestion window as soon as possible.
- bsdetector 12y ago
  Except that Microsoft tested SPDY against pipelining and found that pipelining was essentially just as good. So we're left with a situation where Google could have used HTTP pipelining over SSL (so there's no buggy proxies interfering, just like what SPDY does) and gotten pretty much all the benefit with no extra complications at all, but instead there's old HTTP and a new, much more complicated protocol. And this "head of line blocking" problem... who said it was a problem, Google? In reality you have 4 or more connections that automatically work like spread spectrum where most resources aren't stuck behind a big or slow request. But even if this was an actual problem, a simple hint in the HTML that the resource might take a while and to put other ones on a separate connection would optionally solve this problem, and with almost no extra complexity.

Mojah 12y ago

Very nice research, kudos to everyone involved. I agree with the conclusions, mostly the very last one. > To improve further, we need to restructure the page load process To fully utilise the potential of HTTP/2, we will have to rethink the way we create and manage websites. I've posted more thoughts on this on my blog; https://ma.ttias.be/architecting-websites-http2-era/ https://ma.ttias.be/architecting-websites-http2-era/