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
parent f506b01389
commit c462fcb663
17 changed files with 733 additions and 0 deletions
@@ -0,0 +1,16 @@
+/io latency while 8 concurrent CPU-bound requests run, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
+=======================================================================================================
+/io alone (baseline, no concurrent CPU load)        : total=20 success=20 wall=345ms p50=329ms p99=342ms
+/io while 8x /cpu (naive) run concurrently          : total=20 success=20 wall=390ms p50=365ms p99=383ms
+/io while 8x /cpu-offloaded run concurrently        : total=20 success=20 wall=379ms p50=342ms p99=357ms
+
+This is the real cost of the naive endpoint, and it does not show up by benchmarking
+/cpu in isolation: /io shares the same small event-loop pool with /cpu. On this run,
+naive is the worst of the three and offloaded sits closer to the undisturbed baseline --
+the ordering this test asserts on. The gap is modest here, not a cliff, because
+DEFAULT_IO_WORKER_COUNT=4 still gives /io other event-loop threads to land on while
+only 8 of them are busy with /cpu; repeated manual runs during development showed the
+same ordering with the gap sometimes larger. At higher concurrency, or with a smaller
+ratio of event-loop threads to CPU-endpoint traffic, the same mechanism is what turns
+into the much larger production outage this pattern is known for -- this box is simply
+too small and too lightly loaded, at this concurrency, to force that worse case.