[Matthias247]

with BPS you mean throughput on a single request? On an unconstrained connection (like loopback)? In this case you are mostly measuring CPU efficiency, since for a real world deployment the network connection would likely be the bottleneck. In that real world setup then loss of CPU efficiency becomes a scaling challenge, which actually makes it less RPS.

Btw: A good recommendation for anyone doing benchmarking is to both measure throughput for a single connection, but also throughput for the whole server when using lots of connections (e.g. 100 connections per core, and each connection doing multiple concurrent requests). The latter will point out further scaling issues.

In terms of full system efficiency HTTP/2 vs HTTP/1 (with TLS) is actually not that bad for good implementations - might have 10-50% more cost but in the end the performance critical parts (doing syscalls for TCP sockets) are the same for both. QUIC can be much worse. Well optimized setups (which e.g. use optimized UDP APIs with GSO or even XDP) somewhere between 50-100% more expensive than TCP+TLS setups. And simpler implementations can be 5x as expensive, and might not even scale beyond a single CPU core.