5 ms·

I turned off HTTP2 and HTTP3 a few months ago. I see a few million daily page views: Memory usage has been down, latency has been down, network accounting (ban

by geocar 2y ago

I turned off HTTP2 and HTTP3 a few months ago. I see a few million daily page views: Memory usage has been down, latency has been down, network accounting (bandwidth) is about the same. Revenue (ads) is up. > It _can_ be faster -- that's proven -- but only when networks are slow. It can be faster in a situation that doesn't exist. It sounds charitable to say something like "when networks are slow" -- but because everyone has had a slow network experience, they are going to think that QUIC would help them out, but real world slow network problems don't look like the ones that QUIC solves. In the real world, QUIC wastes memory and money and increases latency on the average case. Maybe some Google engineers can come up with a clever heuristic involving TCP options or the RTT information to "switch on QUIC selectively" but honestly I wish they wouldn't bother, simply because I don't want to waste my time benchmarking another half-baked google fart.

withinboredom 2y ago
The thing is, very few people who use "your website" are on slow, congested networks. The number of people who visit google on a slow, congested network (airport wifi, phones at conferences, etc) is way greater than that. This is a protocol to solve a google problem, not a general problem or even a general solution.
- geocar 2y ago
  Since I buy ads on Google to my site I would argue it’s representative of Google’s traffic. But nice theory.
  - withinboredom 2y ago
    It's not. Think about what you search for on your mobile, while out or traveling, and what you search for on desktop/wifi. They are vastly different. Your traffic is not representative of the majority of searches.
    - geocar 2y ago
      I'm sure the majority of searches are for "google" and "facebook" and you're right in a way: I'm not interested in those users. I'm only interested in searches that advertisers are interested in, but this is also where Google gets their revenue from, so we are aligned with which users we want to prioritise, so I do not understand who you possibly think QUIC is for if not Google's ad business?
      - withinboredom 2y ago
        That's literally what I said; the entire protocol is engineered for google. Not for everyone else. 99.99% of websites out there do not need it.
  - suprjami 2y ago
    No. Google traffic is the Google Search page, Gmail, GSuite like Drive and Meet, and YouTube. You probably aren't hosting those.
    - geocar 2y ago
      Google sells that traffic to me: I'm buying ads from the Google Search Page and from YouTube and from ads Google puts anywhere else, so it is Google's traffic. If google can't serve them an ad, they don't care about them, so QUIC isn't for them, so in order for QUIC to make business-sense to google it has to help them serve more ads. The theory is if QUIC helped anyone out, Google (being huge) would be able to sell more ads to me if I use QUIC as well. In reality, they are able to sell me more ads when I turn off QUIC, which means this theory cannot be true.
replete 2y ago
It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on. Nothing beats real world stats though. Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol? Trying to make my sites load faster led me to experiment with QUIC and ultimately I didn't trust it enough to leave it on with the increase of complexity. [0]: https://kiwee.eu/blog/http-3-how-it-performs-compared-to-http-2/ https://kiwee.eu/blog/http-3-how-it-performs-compared-to-htt...
- withinboredom 2y ago
  > It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on. I mean, Lighthouse is maintained by Google (IIRC), and I can believe they are going to give their own protocol bonus points. > Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol? For stable internet connections, you'll see http2 beat http3 around 95% of the time. It's the 95th+ percentile that really benefits from http3 on a stable connection. If you have unstable connections, then http3 will win, hands down.
- geocar 2y ago
  UDP is problematic because you can't recv() more than one packet at a time, so you get syscall limits that you could just ignore with a TCP-based protocol. There's a trick wasting lots of cores but it's bad for battery-powered devices. There's also iouring and af_xdp that look promising, but they aren't supported as widely as chrome. HTTP2 I can't explain. HTTP2 should be better. I suspect it's probably an implementation bug because I can replicate lab performance and HTTP2 looks good to me in controlled tests. I can always try turning it back on again in 6 months...
  - homebrewer 2y ago
    I don't know which site you're describing, but as a user living very far from major datacenters on an unstable and frequently slow network, HTTP[23] have been the best thing since sliced bread. How it looks in practice is getting hundreds of megabits/s when network is under low load (in the middle of the night, etc), but down to hundreds or even dozens of kilobytes/s in the evening. Sometimes with high packet loss. Always having pings of 100ms or higher (right now it's 120ms to the nearest google.com datacenter, 110ms to bing.com, 100ms to facebook.com, and 250ms to HN). Back when HTTP2 was introduced and started becoming popular, I spent a few weekend hours on writing a short script to do a blind test of HTTP1.1 vs HTTP2 or some major sites where both were supported. H2 won every time, hands down. It was like comparing a 96kbit/s MP3 to a FLAC. > UDP is problematic because you can't recv() more than one packet at a time https://man7.org/linux/man-pages/man2/recvmmsg.2.html https://man7.org/linux/man-pages/man2/recvmmsg.2.html

by geocar 2y ago

withinboredom 2y ago

The thing is, very few people who use "your website" are on slow, congested networks. The number of people who visit google on a slow, congested network (airport wifi, phones at conferences, etc) is way greater than that. This is a protocol to solve a google problem, not a general problem or even a general solution.

geocar 2y ago
Since I buy ads on Google to my site I would argue it’s representative of Google’s traffic. But nice theory.
- withinboredom 2y ago
  It's not. Think about what you search for on your mobile, while out or traveling, and what you search for on desktop/wifi. They are vastly different. Your traffic is not representative of the majority of searches.
  - geocar 2y ago
    I'm sure the majority of searches are for "google" and "facebook" and you're right in a way: I'm not interested in those users. I'm only interested in searches that advertisers are interested in, but this is also where Google gets their revenue from, so we are aligned with which users we want to prioritise, so I do not understand who you possibly think QUIC is for if not Google's ad business?
    - withinboredom 2y ago
      That's literally what I said; the entire protocol is engineered for google. Not for everyone else. 99.99% of websites out there do not need it.
- suprjami 2y ago
  No. Google traffic is the Google Search page, Gmail, GSuite like Drive and Meet, and YouTube. You probably aren't hosting those.
  - geocar 2y ago
    Google sells that traffic to me: I'm buying ads from the Google Search Page and from YouTube and from ads Google puts anywhere else, so it is Google's traffic. If google can't serve them an ad, they don't care about them, so QUIC isn't for them, so in order for QUIC to make business-sense to google it has to help them serve more ads. The theory is if QUIC helped anyone out, Google (being huge) would be able to sell more ads to me if I use QUIC as well. In reality, they are able to sell me more ads when I turn off QUIC, which means this theory cannot be true.

replete 2y ago

It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on. Nothing beats real world stats though. Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol? Trying to make my sites load faster led me to experiment with QUIC and ultimately I didn't trust it enough to leave it on with the increase of complexity. [0]: https://kiwee.eu/blog/http-3-how-it-performs-compared-to-http-2/ https://kiwee.eu/blog/http-3-how-it-performs-compared-to-htt...

withinboredom 2y ago
> It's strange to read this when you see articles like this[0] and see Lighthouse ranking better with it switched on. I mean, Lighthouse is maintained by Google (IIRC), and I can believe they are going to give their own protocol bonus points. > Could this be down to server/client implementation of HTTP2 or would you say its a fundamental implication of the design of the protocol? For stable internet connections, you'll see http2 beat http3 around 95% of the time. It's the 95th+ percentile that really benefits from http3 on a stable connection. If you have unstable connections, then http3 will win, hands down.
geocar 2y ago
UDP is problematic because you can't recv() more than one packet at a time, so you get syscall limits that you could just ignore with a TCP-based protocol. There's a trick wasting lots of cores but it's bad for battery-powered devices. There's also iouring and af_xdp that look promising, but they aren't supported as widely as chrome. HTTP2 I can't explain. HTTP2 should be better. I suspect it's probably an implementation bug because I can replicate lab performance and HTTP2 looks good to me in controlled tests. I can always try turning it back on again in 6 months...
- homebrewer 2y ago
  I don't know which site you're describing, but as a user living very far from major datacenters on an unstable and frequently slow network, HTTP[23] have been the best thing since sliced bread. How it looks in practice is getting hundreds of megabits/s when network is under low load (in the middle of the night, etc), but down to hundreds or even dozens of kilobytes/s in the evening. Sometimes with high packet loss. Always having pings of 100ms or higher (right now it's 120ms to the nearest google.com datacenter, 110ms to bing.com, 100ms to facebook.com, and 250ms to HN). Back when HTTP2 was introduced and started becoming popular, I spent a few weekend hours on writing a short script to do a blind test of HTTP1.1 vs HTTP2 or some major sites where both were supported. H2 won every time, hands down. It was like comparing a 96kbit/s MP3 to a FLAC. > UDP is problematic because you can't recv() more than one packet at a time https://man7.org/linux/man-pages/man2/recvmmsg.2.html https://man7.org/linux/man-pages/man2/recvmmsg.2.html