Performance regression in HTTP/2 codec server path in 5.1.0

[doxlik]

Version

5.1.0

Context

Hi,

I noticed a possible HTTP/2 codec server performance regression after moving from Vert.x 5.0.12 to Vert.x 5.1.0.

This is only about the HTTP/2 codec implementation, not the multiplex implementation.

Environment:

Ubuntu Linux
Java 21
native epoll transport

Benchmark shape:

h2load -n 5000000 -c 8 -m 128 -t 8 http://127.0.0.1:8080

Minimal h2c server returning a small fixed body.

Rough numbers on my machine:

5.0.12:
  usually around 2.15M req/s
  often up to ~2.20M

5.1.0:
  usually around 2.02M–2.10M

So the difference looks roughly like a 5–8% throughput drop in this synthetic HTTP/2 hot-path benchmark, and h2load reported request latency also gets worse.

I collected async-profiler CPU/allocation profiles. Allocation did not look significantly worse overall. CPU looked like a distributed overhead increase around the new HTTP/2 request/response path, especially around:

HttpRequestHeaders validate/sanitize
HttpRequestHead / HttpResponseHead
HttpServerRequestImpl / HttpServerResponseImpl
DefaultHttp2ServerStream.writeHead
request dispatch / stream close handling

My current understanding is that this may be related to the HTTP/2 codec path now going through the generic HTTP stream/request/response model, while HTTP/1 still has specialized Http1ServerRequest / Http1ServerResponse classes.

Question: would it make sense for the HTTP/2 codec server path to also have a specialized request/response fast path, similar to HTTP/1, while keeping the generic stream model for HTTP/2 multiplex and HTTP/3?

I am not asking to revert the 5.1 HTTP stream architecture. I wanted to ask whether this performance tradeoff is intentional/acceptable, or whether a specialized HTTP/2 codec path would be considered if it can be done cleanly.

[vietj]

that would mean analysis, we cannot really indeed revert and want to keep the new implementation to avoid proliferation of code to support, I think with the multiplex architecture it might actually have more impact

[vietj]

eventually also we will at some point move HTTP/1.1 to the new architecture as well, it might give significantly worse raw performance but on the long run this is what is sustainable and will be capable to provide an overall better architecture with unified middleware pipeline