Claude
c462fcb663
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.
9 lines
609 B
Plaintext
9 lines
609 B
Plaintext
I/O-bound endpoint (/io, Mono.delay(300ms)), concurrency=600, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
|
|
==============================================================================================================
|
|
webflux (netty) : total=600 success=600 wall=897ms p50=596ms p99=780ms
|
|
|
|
Mono.delay() never parks a thread -- the event loop schedules a timer callback and
|
|
goes back to the selector loop immediately. Wall time for 600 concurrent requests
|
|
stays close to a single 300ms round, same shape as virtual threads' /io result in
|
|
../virtual-threads-benchmark/docs/output/01-io-bound-benchmark.txt.
|