Add Vert.x: reactive JVM toolkit on Netty (~15k ⭐)#72
Merged
MDA2AV merged 2 commits intoMDA2AV:mainfrom Mar 23, 2026
Merged
Conversation
Owner
|
/benchmark |
Collaborator
Author
|
Benchmark run triggered for vertx — all profiles. Results will be posted here when done 🚀 Really curious about this one — Netty's event loop is battle-tested and Vert.x should show what the JVM can do with reactive I/O. Expecting some strong numbers. |
|
🚀 Benchmark run triggered for |
Owner
|
/benchmark |
|
🚀 Benchmark run triggered for |
Benchmark ResultsFramework: Full log |
Owner
|
@BennyFranciscus look into compression, seems that it isnt compressing every request. Also why are upload values so low? |
The compression endpoint was conditionally checking Accept-Encoding and only serving gzip when the header was present. The benchmark doesn't send Accept-Encoding, so responses were uncompressed. Now always serves the pre-computed gzip response, matching the pattern used by other frameworks (Kemal, Express, Phoenix, etc.). Also disabled file upload writes to disk in BodyHandler for better upload throughput — keeps body in memory only.
Collaborator
Author
|
@MDA2AV Good catch on compression — same bug as Phoenix. Was checking On upload: the numbers (253 req/s at 64c, 107 at 256c) are actually in a similar range to Phoenix (174, 156, 151). These are ~100MB uploads being fully buffered in memory per request. JVM's GC handles it but at 512c that's ~50GB of concurrent body data which explains the 25GB memory and lower throughput. I also disabled BodyHandler's disk-based file upload handling so it's pure in-memory now — might help a bit. Should be good to re-benchmark when ready 👍 |
Owner
|
/benchmark |
|
🚀 Benchmark run triggered for |
Benchmark ResultsFramework: Full log |
Collaborator
Author
|
Post-fix re-benchmark looks solid — compression is working consistently now: Key numbers (post compression fix):
Upload is still in that 100-250 req/s range (255 at 64c), which tracks with what we see from other JVM frameworks handling 100MB bodies. Everything looks clean — ready to merge whenever you're happy with it 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Vert.x — Eclipse Vert.x 4.5.14
Adds Eclipse Vert.x (~15k ⭐) to HttpArena — the reactive toolkit for building high-performance JVM applications.
Why Vert.x?
Vert.x is the event-driven engine underneath Quarkus. HttpArena already has Spring (Tomcat), Spring (Jetty), and Quarkus (Vert.x/Netty) — but not raw Vert.x itself. This is the "framework vs engine" comparison:
How much overhead does Quarkus's abstraction add on top of raw Vert.x? Now we can find out.
Implementation
vertx-webfor routingexecuteBlocking()(event loops never block)All tests
26/26 validation checks pass locally.
cc @vietj @tsegismont — would be cool to see how raw Vert.x stacks up against the frameworks built on top of it!