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.
18 lines
1.3 KiB
Plaintext
18 lines
1.3 KiB
Plaintext
CPU-bound endpoint (/cpu vs /cpu-offloaded, 20,000x SHA-256), concurrency=60, 2 vCPU sandbox, Spring Boot 4.1.1 / JDK 25.0.4.1
|
|
==============================================================================================================================
|
|
LoopResources.DEFAULT_IO_WORKER_COUNT (Netty event-loop threads) = 4
|
|
Runtime.availableProcessors() (Schedulers.parallel() thread count) = 2
|
|
|
|
webflux naive (Mono.fromCallable, no subscribeOn) : total=60 success=60 wall=302ms p50=145ms p99=288ms
|
|
webflux offloaded (subscribeOn(Schedulers.parallel())) : total=60 success=60 wall=271ms p50=142ms p99=261ms
|
|
|
|
Counter-intuitive result, and worth stating honestly rather than forcing the expected
|
|
story: on THIS box, the two wall times are close, because Reactor Netty's default event-
|
|
loop pool (DEFAULT_IO_WORKER_COUNT = max(availableProcessors(), 4) = 4 here) is actually
|
|
LARGER than Schedulers.parallel()'s pool (sized to availableProcessors() = 2). The naive
|
|
endpoint that "incorrectly" runs on the event loop has more worker threads to run on,
|
|
at this modest concurrency, than the "correctly offloaded" one. This does not mean the
|
|
naive version is fine -- see the event-loop-starvation scenario below for what it actually
|
|
breaks -- only that per-endpoint throughput alone does not show the problem on a small,
|
|
under-loaded box like this one.
|