[mgaunard]

Most likely the parallel requests are done using a single connection.

So of course HTTP/2 will outperform, that's what it's designed to do.

Now try again, but use one connection per thread, and connect it before you start benchmarking, i.e. use it the way it's meant to be used.

[mattrobenolt]

The tests cover both cases if you read.

But either way, yes, that's fundamentally a benefit of being able to use HTTP. We can multiplex multiple sessions over one underlying connection.

[mgaunard]

Multiplexing is already done for you by your kernel, it's called having multiple TCP sessions.

The whole premise of HTTP/[23] is to do the same thing as you do with N TCP sessions, but paying for the session establishment latency only once instead of N times.

And most applications couldn't care less about that latency, because you only do it once.

[mattrobenolt]

My apologies for not meeting your bar. I guess you missed the parts where it's faster in a lot of other cases too, and not slower in any.

To me, the fact that it's not slower at all is the big win. I didn't anticipate that the results of this are going to say "this is 5x better". The stereotype is that if it's over HTTP, it must be slower.

And by every measure, it's not slower. In cases, that may be edge to you, or don't care about extra latency, they're still improved. Why would you not want something that's generically better?

There are many other things that are beneficial with using HTTP as a transport that haven't even been discussed here since this was entirely focused on performance. Without at least matching in performance, not many of the other things would matter.

[mgaunard]

99% of benchmarks are wrong and lead to misleading conclusions. You didn't provide the code so it cannot be independently reviewed.

This article IMO contributes to spreading the misinformation that HTTP/[23] is useful for many applications, when it is actually a very niche protocol only useful to web browsers, or other similar applications that continuously need to connect to endpoints they don't know in advance.

Web tech has already done sufficient damage by pushing HTTP/1.1 and SSL everywhere in IT, we don't need to force those protocols onto everything.

[hardwaresofton]

Would you mind expanding on other protocols that would be better?

I personally cant think of a protocol I’d rather have go everywhere than QUIC/HTTP3.

Forced TLS is disappointing (there’s some discussion), but the upside is that this means SNI works and you can now very easily route UDP traffic via SNI.

Given the flexibility of HTTP/3 I wouldnt mind having it everywhere.

[mgaunard]

HTTP/3 is just a way to have multiple reliable connections with less latency in establishing them than with TCP.

What you can use instead is simply TCP.

TCP is simple, mature, has all kinds of support in software and hardware.

The only advantage of HTTP/3 doesn't matter to most use cases and doesn't warrant its complexity and throwing away all the networking ecosystem built on TCP.

[mattrobenolt]

Check your bias. This was clearly communicated as an experiment with surprising results. In some contexts, we don't have a choice but to support HTTP. So simply wanted to see how it stood up to a traditional mysql client.

But you do you.

[mattrobenolt]

Also ever heard of gRPC? It's pretty popular and widely used. Whether you like it or not or whether it's the most optimal in theory, in practice HTTP is heavily heavily used for communicating between components.

To me, HTTP sits in a similar boat as JSON. Is it perfect? Is it good? Not necessary. But it's extremely extremely scrutinized and optimized due to its ubiquity in ways that other protocols and formats haven't been.

This was the entire point of this experiment and it's proved successful. The bias I wanted to challenge is exactly what you mentioned. Turns out, using HTTP as a transport and protobuf for encoding (which is basically gRPC) is comparable.