Claude
09631dcaab
Fixes found during self-correction before publishing: - /stream used Flux.interval(), which ticks on its own wall-clock schedule independent of downstream demand and threw OverflowException under a slow subscriber; switched to Flux.range(), which has no independent production schedule and can never outrun demand. - Single-trial HTTP load tests on this shared sandbox swung by more than 50% run to run (795ms-1247ms observed on the identical /io endpoint back to back) -- large enough to flip which threading model looked faster. Fixed by taking the median of 5 independent trials for the I/O-bound benchmark and the median of 3 for the event-loop-starvation benchmark, rather than reporting a single noisy run as if it were precise. - The event-loop-starvation test's first cut used only 8 concurrent /cpu requests as background load, which drained through the 4 event-loop threads well inside the /io measurement window and produced an inconsistent, sometimes-inverted result across runs; raising to 60 fixed the under-loading problem but still flaked once during verification (372ms vs 374ms p99, a real tie). Final fix: 150 concurrent requests plus the median-of-3 trials above. Also adds StreamBackpressureTest, a StepVerifier proof that the /stream endpoint never emits ahead of its subscriber's outstanding requests, and updates the module's docs to report the de-noised numbers with an explicit methodology note on how they compare to the single-trial platform/virtual- thread numbers reused from a different post.
13 lines
941 B
Plaintext
13 lines
941 B
Plaintext
I/O-bound endpoint (/io, Mono.delay(300ms)), concurrency=600, median of 5 trials, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
|
|
==================================================================================================================================
|
|
webflux (netty) : total=600 success=600 wall=569ms p50=455ms p99=510ms
|
|
|
|
Mono.delay() never parks a thread -- the event loop schedules a timer callback and
|
|
goes back to the selector loop immediately. A single trial at this concurrency swung
|
|
50%+ between back-to-back runs on this shared sandbox -- bigger than the gap being
|
|
measured -- so the number above is the median of 5 independent trials, not
|
|
one shot. Even so it lands in the same range as virtual threads' /io result in
|
|
../virtual-threads-benchmark/docs/output/01-io-bound-benchmark.txt (a single trial):
|
|
treat any single-run percentage gap between WebFlux and virtual threads here as
|
|
noise-level, not a reliable ranking.
|