Can .NET ThreadPool minThreads Cause Latency Spikes Under Concurrent Requests?

Goal

Determine whether raising the .NET ThreadPool minimum thread count can prevent request-queueing latency that appears only under concurrent load in an ASP.NET Core application targeting .NET 8.

Constraints and uncertainty

The default minThreads value is derived from static heuristics and does not adapt to workload characteristics. Under bursty traffic, Kestrel may accept more connections than the ThreadPool can immediately serve, so excess requests wait in the queue. The documented interaction between Kestrel’s per-endpoint connection limit and ThreadPool scaling is incomplete, making it unclear whether adjusting minThreads alone resolves the spike or merely shifts the bottleneck.

Specific questions:

• Does increasing ThreadPool minimum threads reduce p99 latency during concurrent bursts without creating starvation elsewhere?
• Which limit takes precedence when Kestrel’s connection cap and the ThreadPool’s available thread count conflict?
• What metric distinguishes ThreadPool queueing from GC pause latency under the same concurrent load?