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.
62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
# 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`](../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
|
|
|
|
```bash
|
|
./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](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`](src/main/java/com/ankurm/vthreadswebflux/ReactiveDemoController.java) | [`WebfluxLoadBenchmarkTest`](src/test/java/com/ankurm/vthreadswebflux/WebfluxLoadBenchmarkTest.java) | [`01`](docs/output/01-io-bound-webflux.txt) |
|
|
| 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`](docs/output/02-cpu-bound-webflux.txt) |
|
|
| Event-loop starvation: what the naive CPU endpoint actually costs *other* traffic on the same server | [`CpuWork`](src/main/java/com/ankurm/vthreadswebflux/CpuWork.java) | same | [`03`](docs/output/03-event-loop-starvation.txt) |
|
|
|
|
## Documentation chapters
|
|
|
|
1. [WebFlux benchmark methodology and results](docs/01-webflux-benchmark-methodology.md) --
|
|
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`](../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](https://ankurm.com/leveraging-virtual-threads-in-spring-boot-3-4-building-high-throughput-services/).
|
|
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](LICENSE).
|