A Tokio performance write-up from RustConf names the failure modes, including a blocking-pool ceiling near 50,000 tasks per second

Sources: post, HN discussion
Summary: Tokio's blocking pool is a single global resource, and the author reports negative performance effects at roughly 50,000 blocking tasks per second on a 32-core host, with spawn_blocking becoming visible in flamegraphs, noting that Tokio 1.52.0 briefly shipped a sharded blocking queue, 1.52.1 reverted it after a regression that could hang spawn_blocking, and PR #8337 re-landed it as an unstable feature disabled by default. Two failure shapes are specific enough to check for, a metrics registry behind a mutex or read-write lock that stalls every worker at once, because each worker eventually schedules a task that blocks on the same lock and stealing becomes impossible, and a co-tenant process with many threads that delays worker wakeups by 10 to 20 ms, which the author observed during incremental Java to Rust migrations at Amazon. The named diagnostic is Tokio's schedule latency histogram, the gap between a task becoming ready and the runtime polling it, and every measurement is the author's own in a post dated 2026-09-13.
Why it matters: The version history around PR #8337 and the schedule latency histogram are both checkable by a reader directly, and the author builds dial9, the Tokio tracing tool named throughout the post.