Increase Netty workerThreads or accept acceptor‑queue‑induced latency bursts under high concurrency?

The goal is to keep request latency low when a Ktor server handles many concurrent connections while preserving overall throughput.

With the Netty engine, the default acceptor queue size caps the number of requests that can be processed simultaneously, and there is no stable API to adjust this queue independently of the worker thread count. Raising the workerThreads setting allows more concurrent connections but introduces additional context‑switch overhead, which can increase latency if the pool is oversized.

Given this trade‑off, it is unclear what workerThread configuration yields the best latency‑throughput balance, whether monitoring the acceptor queue depth would help predict bursts, or if alternative engine tuning might be preferable.

What workerThread count minimizes latency spikes without causing excessive context switching? Is there a reliable way to observe acceptor queue utilization under load?