3 ms·

That example seems to be arbitrarily constructed to benefit from parallel connections and does not reflect typical HTTP transfer payloads. In reality, Google m

That example seems to be arbitrarily constructed to benefit from parallel connections and does not reflect typical HTTP transfer payloads. In reality, Google mostly failed to show scientific proof that HTTP/2.0 provides beneficial on typical connections - one major reasoning why even introducing QUIC in HTTP/3. A lot of "amateur benchmarks" float the net claiming HTTP/2 speed superiority, but often the measurements are flawed (not taking TCP peculiarity like congestion control into account or even including it in the analysis; classic fault is failure to disable TCP initcwnd caching or flushing the cache when doing benchmarks).

heipei 6y ago
Anecdotal, but I've encountered so many legacy HTTP/1 applications on typical corporate VPN networks where the latency was horrible (due to the VPN and also due to the backend responses adding even more latency). What I've done in some cases is just thrown an HTTP/2 proxy in front of these and saw an immediate and very user-perceptible performance improvement for the user. So much so that people kept asking why using the proxied version I stood up was so much faster than going directly to the origin server.
- ktpsns 6y ago
  This is actually quite a good example that websites are bloated and this problem is tried to be solved or worked-around at the protocol level. Which is adding even more bloat and craft in terms of code complexity. These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.
  - heipei 6y ago
    Yes, some websites are certainly bloated and for those it is simply a band-aid. But other websites really do make dozens of requests and there is no way to bundle or reduce these. Just think about a photo-sharing website or forum which loads thumbnails or user avatars for dozens of users in a discussion. This is not something that you can sprite together.
    - labawi 6y ago
      Sure you can. Even without javascript. If you really wanted to, you could even make it work in IE 5, in a single request (I think). I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind. You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.
Nullabillity 6y ago
It is a bit over the top, but the patterns are still indicative of the naive approaches you'd typically start out with. Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.
cogman10 6y ago
I've seen a lot of compromises around REST because of http 1.1 overhead. A great example of this happens when someone wants to query for a list of resources. The rest way for this would be to do requests like this get /foo/1 get /foo/2 get /foo/3 However, unless you spin up a bunch of parallel connections (wasting a bunch of resources both in the servers and the client), you are going to experience performance issues. The compromise is to create endpoints that look like this post /foo [1,2,3] That saves the connection problem but creates a bunch of new issues. The client can send arbitrary request sizes to single servers (making LBing more difficult). It's not idiomatic, which means things like Http caching simply can't be used (or at least are less effective). A lot of http clients will do auto-retry but only for idempotent verbs, that's gone, you now need to implement all that stuff yourself. http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system. Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2. All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over. Now, is this super scientific? No. Rather it's based on what I've seen in the field. Http2 has a ton of benefits when doing a lot of small message communication.

heipei 6y ago

Anecdotal, but I've encountered so many legacy HTTP/1 applications on typical corporate VPN networks where the latency was horrible (due to the VPN and also due to the backend responses adding even more latency). What I've done in some cases is just thrown an HTTP/2 proxy in front of these and saw an immediate and very user-perceptible performance improvement for the user. So much so that people kept asking why using the proxied version I stood up was so much faster than going directly to the origin server.

ktpsns 6y ago
This is actually quite a good example that websites are bloated and this problem is tried to be solved or worked-around at the protocol level. Which is adding even more bloat and craft in terms of code complexity. These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.
- heipei 6y ago
  Yes, some websites are certainly bloated and for those it is simply a band-aid. But other websites really do make dozens of requests and there is no way to bundle or reduce these. Just think about a photo-sharing website or forum which loads thumbnails or user avatars for dozens of users in a discussion. This is not something that you can sprite together.
  - labawi 6y ago
    Sure you can. Even without javascript. If you really wanted to, you could even make it work in IE 5, in a single request (I think). I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind. You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.

Nullabillity 6y ago

It is a bit over the top, but the patterns are still indicative of the naive approaches you'd typically start out with. Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.

cogman10 6y ago

I've seen a lot of compromises around REST because of http 1.1 overhead. A great example of this happens when someone wants to query for a list of resources. The rest way for this would be to do requests like this get /foo/1 get /foo/2 get /foo/3 However, unless you spin up a bunch of parallel connections (wasting a bunch of resources both in the servers and the client), you are going to experience performance issues. The compromise is to create endpoints that look like this post /foo [1,2,3] That saves the connection problem but creates a bunch of new issues. The client can send arbitrary request sizes to single servers (making LBing more difficult). It's not idiomatic, which means things like Http caching simply can't be used (or at least are less effective). A lot of http clients will do auto-retry but only for idempotent verbs, that's gone, you now need to implement all that stuff yourself. http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system. Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2. All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over. Now, is this super scientific? No. Rather it's based on what I've seen in the field. Http2 has a ton of benefits when doing a lot of small message communication.