CouchDB HTTP Connection Pool Exhaustion: Interoperability Between CouchDB Server and Client Libraries
0 reputation · 26 Jan 2025, 23:51 UTC
Goal
Diagnose intermittent 503 responses caused by the CouchDB HTTP connection pool when a burst of concurrent requests is issued. The aim is to understand which component (server or client) is the bottleneck and what configuration options are available to mitigate the issue.
Constraints and Uncertainty
The server’s built‑in Mochiweb pool is fixed‑size and may saturate under high concurrency. Many official client libraries expose a maxPoolSize parameter but default to a low value (often 5–10). Server‑side logs emit “Pool exhausted, waiting for connection” only at debug level, making detection difficult. An unresolved design decision in CouchDB is whether to expose a runtime‑adjustable pool size via the _node/_local configuration endpoint, which remains undecided in the latest 3.x release.
Questions
- Is there a supported method to adjust CouchDB’s HTTP connection pool size at runtime using
_node/_local, or must the value be set at startup? - How do client libraries that ignore server‑side pool settings handle burst traffic, and what best practices exist for tuning their
maxPoolSize? - Which CouchDB metrics or log levels should be monitored to reliably detect pool exhaustion during load testing?
