/io latency while 150 concurrent CPU-bound requests run, median of 3 trials, 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=347ms p50=332ms p99=346ms
/io while 150x /cpu (naive) run concurrently         : total=20 success=20 wall=995ms p50=742ms p99=950ms
/io while 150x /cpu-offloaded run concurrently       : total=20 success=20 wall=731ms p50=693ms p99=697ms

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. Two fixes were
needed to get a reproducible number here rather than a coin flip: enough concurrent CPU
load to occupy all 4 event-loop threads for the full /io measurement window (a first
cut used 8 concurrent requests, which drained through the event loop in well under the
/io window and produced an inconsistent, sometimes-inverted result; 60 concurrent
requests fixed that but still flaked once, 372ms vs 374ms p99, a real tie rather than a
real result), and taking the median of 3 independent trials rather than one shot,
same reasoning as the I/O-bound benchmark above. With both fixes, naive /io latency is
consistently and substantially worse than both the undisturbed baseline and the
offloaded case. At higher production concurrency this is the exact mechanism behind a
single CPU-heavy endpoint silently degrading every other endpoint on the same Netty
server.