Files
spring-async-demo/virtual-threads-benchmark-webflux
Claude c462fcb663 Add virtual-threads-benchmark-webflux: the WebFlux leg of the three-way benchmark
Re-uses the platform/virtual-thread transcripts already committed in
virtual-threads-benchmark rather than re-measuring them, and adds a WebFlux
module measured the same way (client-side java.net.http.HttpClient load
generator against a real Netty server). Covers I/O-bound throughput, a
naive-vs-offloaded CPU-bound comparison that turned up a real, counter-
intuitive fact about this sandbox's default thread-pool sizes
(LoopResources.DEFAULT_IO_WORKER_COUNT=4 vs Schedulers.parallel()'s
availableProcessors()=2), and an event-loop-starvation scenario showing
what the naive endpoint actually costs unrelated /io traffic on the same
server. Companion code for the ankurm.com post "Virtual Threads vs WebFlux
vs Platform Threads: Benchmarks and a Decision Framework." Also fixes the
root README's module table, which was missing the virtual-threads-benchmark
row from an earlier commit.
2026-09-19 08:31:51 +00:00
..

virtual-threads-webflux-benchmark

Companion module for the ankurm.com post "Virtual Threads vs Reactive (WebFlux) vs Platform Threads: Benchmarks and a Decision Framework." This module is the WebFlux leg of that three-way comparison; the platform-thread and virtual-thread legs live in the sibling module ../virtual-threads-benchmark, built for a different ankurm.com post and reused here rather than re-run, so the platform/virtual numbers quoted in this post are the same numbers, not a second measurement of the same thing.

Every number below is from a real concurrent load run against a real running embedded Netty server on this JDK, using the identical client-side load generator (java.net.http.HttpClient, virtual-thread executor, client-side only) as the sibling module.

Versions (verified against repo1.maven.org maven-metadata.xml and Spring Boot's own spring-boot-dependencies POM, not aggregators)

Component Version Notes
JDK 25 (Temurin 25.0.4.1+1) same as ../virtual-threads-benchmark
Spring Boot 4.1.1 latest GA at time of writing
Spring Framework 7.0.9 latest GA
Reactor managed by spring-boot-dependencies 4.1.1 version not pinned directly; see this module's effective POM

Quickstart

./scripts/run-all.sh    # regenerates every file in docs/output/ from a real test run
./scripts/run.sh         # start on :8080

Requires JDK 25 and Maven. This module's own benchmark ran on the same 2 vCPU sandbox as ../virtual-threads-benchmark -- see docs/01-webflux-benchmark-methodology.md for why that matters and what it means for the numbers below.

What's demonstrated where

Area Source Test Transcript
I/O-bound throughput: WebFlux, 600 concurrent, same shape as virtual threads ReactiveDemoController WebfluxLoadBenchmarkTest 01
CPU-bound throughput: naive (event loop) vs offloaded (Schedulers.parallel()), 60 concurrent -- and why the gap is smaller than expected on this box same same 02
Event-loop starvation: what the naive CPU endpoint actually costs other traffic on the same server CpuWork same 03

Documentation chapters

  1. WebFlux benchmark methodology and results -- I/O-bound, CPU-bound naive vs offloaded, and the event-loop-starvation scenario the isolated CPU benchmark can't show, all on this sandbox's real hardware

A note on this module's relationship to ../virtual-threads-benchmark

../virtual-threads-benchmark already contains a real, re-run platform-thread vs virtual-thread benchmark on this exact hardware and JDK, built for Virtual Threads on Spring Boot 4.1. This module deliberately does not re-measure that comparison -- it reuses those committed transcripts and adds only the WebFlux leg, using the same client-side load-generation method, so the three-way post can quote one consistent measurement approach across all three models instead of stitching together benchmarks run different ways.

License

MIT -- see LICENSE.