News for hackers. Stuff that matters.
Re:The HTTP/2 implementation by Steltek on Thursday September 17, 2015 @12:27PM (#10234320)
HTTP 1.1 - 0.64s, 2.0 - 0.60s. Firefox Aurora, Linux.

I'd like to know more about how this benchmark runs and what it's actually measuring. Page load times and responsiveness are notoriously hard to define.

I don't mean to nitpick the benchmark too much, it's obviously measuring something, but it's also nice to be able to weigh it against other tests and design goals.

Re:The HTTP/2 implementation by Twirrim on Thursday September 17, 2015 @01:17PM (#10234711)
Try https://http2.golang.org/, while it's not benchmarking per se, there are some fun examples under https://http2.golang.org/gophertiles and the code is all here: https://github.com/bradfitz/http2/tree/master/h2demo
Re:The HTTP/2 implementation by chucky_z on Thursday September 17, 2015 @01:52PM (#10234957)
This test 'cheats' in favor of HTTP 2.0. The problem is that there are ways around the HTTP 1.1 limitation of 'one connection, one thing,' and this test uses absolutely none of those ways. It makes a connection, receives an image, closes a connection, opens a connection, receives an image,... 200 times.

The HTTP/2 test does exactly what it's designed to do: opens a lot of connections and receives the images pretty much all at once.

This isn't to downplay HTTP/2, but it's something that should be noted for _this_ test.

Re:The HTTP/2 implementation by stdbrouw on Thursday September 17, 2015 @03:40PM (#10235585)
Alternatively you could say that using all of the various tricks to speed up HTTP 1.1 would be cheating in favor of 1.1. Personally, I prefer not to have to think about how to optimize my websites; just let the protocol figure it out for me.
Re:The HTTP/2 implementation by Steltek on Thursday September 17, 2015 @09:24PM (#10237058)
Elsewhere in the comments here, it's mentioned that nginx doesn't yet have server push so maybe it's fair to call these naive test setups then? I'd certainly buy that HTTP/2 has more head room for acceleration and optimization but I'm curious what the difference there would be. However, it starts to sound like programming language benchmarks where the test servers aren't setup in an "idiomatic" manner.

I believe that HTTP/2 isn't opening many connections. It's opening one TCP connection and multiplexing many requests through that. This would allow for exploiting a pre-warmed TCP connection in subsequent requests. I've always felt that was a flaw in HTTP/2: with minor modifications, that multiplexing protocol could have been split out.

I'm interested to see how HTTP/2 could accelerate your modern jumbo media websites. The ones with a dozen or so tracking bugs, ads, etc. All splattered across multiple domains with ad servers that aren't quite as zippy as one would wish.

Re:The HTTP/2 implementation by knd775 on Thursday September 17, 2015 @01:06PM (#10234621)
It tells you what it is measuring on the page. It downloads an array of 200 small images from a CDN to make a single larger image and times the process.