Nim httpclient connection pool exhaustion under high async concurrency

Nim's standard library httpclient reuses TCP connections via keep-alive through an internal connection pool. In applications that issue many concurrent requests with asyncdispatch, the pool can saturate when the number of in-flight requests exceeds the hard-coded idle-connection limit per host. Because the stdlib does not expose a public API to tune the pool size or eviction timer, long-running services may experience intermittent blocking or failures that are difficult to distinguish from server-side limits.

This behavior applies to Nim versions up to 2.0.0; future releases may alter the pool implementation or expose configuration options. Third-party HTTP clients often implement their own pooling mechanisms, so symptoms observed with the stdlib module may not generalize to those libraries.

Given the fixed internal limit and lack of tunable parameters, what diagnostic approach can confirm whether pool exhaustion is causing intermittent request delays without modifying stdlib internals? Should application-level concurrency be capped to match the hard-coded pool size, or are there observable signals that indicate saturation before requests block? How can teams verify that a specific Nim version still enforces the same hard-coded limit before relying on that assumption in production?