3 ms·

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

by Steltek 11y ago

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.

knd775 11y ago
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.
Twirrim 11y ago
Try https://http2.golang.org/ https://http2.golang.org/, while it's not benchmarking per se, there are some fun examples under https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles and the code is all here: https://github.com/bradfitz/http2/tree/master/h2demo https://github.com/bradfitz/http2/tree/master/h2demo
chucky_z 11y ago
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.
- stdbrouw 11y ago
  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.
- Steltek 11y ago
  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.

by Steltek 11y ago

knd775 11y ago

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.

Twirrim 11y ago

Try https://http2.golang.org/ https://http2.golang.org/, while it's not benchmarking per se, there are some fun examples under https://http2.golang.org/gophertiles https://http2.golang.org/gophertiles and the code is all here: https://github.com/bradfitz/http2/tree/master/h2demo https://github.com/bradfitz/http2/tree/master/h2demo

chucky_z 11y ago

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.

stdbrouw 11y ago
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.
Steltek 11y ago
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.