3 ms·

Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?

mohamedattahri 12y ago
Good point, but domain sharding is just a clever optimization (hack) to emulate some of the parallelism provided by HTTP/2 out of the box.
- jtruk 12y ago
  Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!
- lomnakkus 12y ago
  Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing. Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up. [1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.
  - kbenson 12y ago
    I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.
- mohamedattahri 12y ago
  Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.
- patrickmcmanus 12y ago
  domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.) Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer. Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.
LaurentVB 12y ago
Not sure, isn't the whole point of pipelining to avoid these domain-sharding workarounds? This test case shows that the performance is better with the same code. The invert test case would show that the code is more complex (because of sharding) for the same performance (actually not quite, because of multiple handshakes).
- Kudos 12y ago
  The whole point of pipelining is to avoid expensive TCP operations. Domain-sharding is effectively a workaround for the workaround (limiting connections to hosts). You can actually do both domain-sharding and still use only a single TCP connection. SPDY/HTTP2 will reuse existing connections if they receive the same cert/ip combo. It's the best of both worlds while http1 still has some marketshare.
nfriedly 12y ago
I wouldn't say so. Domain sharding is a hack, and not every website implements it, so I think this is a fair comparison. Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.
invisible 12y ago
Yes and no. It would speed up the client receiving the images but at the detriment of flooding servers with connections (even moreso bad if HTTPS). I assume since this is on golang's site, this is also trying to show off the difference with just using the HTTP2 vs HTTP package.
- mohamedattahri 12y ago
  The page is also a reference server implementation for people working on clients are well.
  - zserge 12y ago
    Does anyone know when the HTTP/2 client for Go will be available? And, are they likely to include http/2 into a standard net/http package?

Good point, but domain sharding is just a clever optimization (hack) to emulate some of the parallelism provided by HTTP/2 out of the box.

jtruk 12y ago
Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!
lomnakkus 12y ago
Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing. Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up. [1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.
- kbenson 12y ago
  I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.
mohamedattahri 12y ago
Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.
patrickmcmanus 12y ago
domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.) Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer. Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.

LaurentVB 12y ago

Not sure, isn't the whole point of pipelining to avoid these domain-sharding workarounds? This test case shows that the performance is better with the same code. The invert test case would show that the code is more complex (because of sharding) for the same performance (actually not quite, because of multiple handshakes).

Kudos 12y ago
The whole point of pipelining is to avoid expensive TCP operations. Domain-sharding is effectively a workaround for the workaround (limiting connections to hosts). You can actually do both domain-sharding and still use only a single TCP connection. SPDY/HTTP2 will reuse existing connections if they receive the same cert/ip combo. It's the best of both worlds while http1 still has some marketshare.

nfriedly 12y ago

I wouldn't say so. Domain sharding is a hack, and not every website implements it, so I think this is a fair comparison. Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.

invisible 12y ago

Yes and no. It would speed up the client receiving the images but at the detriment of flooding servers with connections (even moreso bad if HTTPS). I assume since this is on golang's site, this is also trying to show off the difference with just using the HTTP2 vs HTTP package.

mohamedattahri 12y ago
The page is also a reference server implementation for people working on clients are well.
- zserge 12y ago
  Does anyone know when the HTTP/2 client for Go will be available? And, are they likely to include http/2 into a standard net/http package?