Sys prop configuration to leverage SSL heap buffer pooling

[franz1981]

This fix the weird performance problem observed at #41880 (comment)

if the users run the quarkus application with
-Dquarkus.http.server.ssl.jdk.bufferPooling=true -Dvertx.reuseNettyAllocators=true (latter, see eclipse-vertx/vert.x#5292)

It is still missing:

• Reactive SQL Client SSL
• gRPC SSL
• vertx http client-side (if we expose it)

I'm not aware in which other Quarkus extensions (.e.g OTel?) we are using SSL/TLS from Vertx: if we do, we should provide a similar fix there.

[franz1981]

@geoand I'm opened to suggestions on how to better let users to consume it.

To be fair -Dvertx.reuseNettyAllocators=true should always be set, it's low risk and good impact.
Whilst for quarkus.http.server.ssl.jdk.bufferPooling I have tried to make it "hidden" enough, since, with Vertx 5 it will be the default behaviour (both, actually) - and I don't think we want to deprecate or else....

IDK if it's ok the way I've implemented it because HttpServerOptionsUtils is consumed by VertxHttpRecorder

[geoand]

This is more for @cescoffier to decide

[franz1981]

@mabartos can you please check the checklist in description if TLS/SSL is used in any of the missing changes?

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 49ee0bc.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

[geoand]

I'm not aware in which other Quarkus extensions (.e.g OTel?) we are using SSL/TLS from Vertx: if we do, we should provide a similar fix there.

Correct

[franz1981]

I've quickly verified, by running a debug session vs getting-started (dev branch) - that the 2 args work as intended.
@mabartos need to add them in order to benefit of these changes, but please check if you need to have the gRPC fix and the reactive SQL one

[mabartos]

@franz1981 Thanks for these changes! We will probably run some more comprehensive analysis after Xmas.

For Keycloak purposes, we don't use gRPC SSL, or reactive SQL SSL. AFAIK, not even Vert.x HTTP client.

[franz1981]

Lovely, I would like to ask more people in the community if they can give it a shot, maybe @vsevel - but it's approaching Christmas so, don't expect the world to be reactive eheh

[vsevel]

I am making a note of it. how should this be tested? where can I expect the improvements?

[franz1981]

Thanks @vsevel for the quick response: it should benefit when http (1.1 and 2) TLS/SSL is involved.
If you have other "secured" cases which include gRPC, Reactive SQL, http client side...let me know so I can provide a fix for these too 🙏

The benefits are both CPU usage and heap allocation pressure, since, without these fixes, on SSL/TLS every decoding/encoding of data just allocate a giant unpooled heap buffer.
These changes uses heap pooled buffers, instead, which despite increases the application idle memory footprint (in terms of heap old gen occupancy) it should reduce the demand under load.