mongodb-connection

A MongoDB connection-optimization skill covering client connection configuration—pools, timeouts, and instantiation patterns—across all officially supported driver languages (Node.js, Python, Java, Go, C#, Ruby, PHP, and others). It applies when working on code that creates or configures a MongoDB client, sets up connection pools, troubleshoots connection errors such as ECONNREFUSED, timeouts, or pool exhaustion, or optimizes connection-related performance. Typical scenarios include serverless functions, API endpoints, high-traffic applications, long-running tasks with concurrency, and debugging connection failures.

Its core principle is context before configuration: never add pool parameters or timeout settings without first understanding the application's environment, because arbitrary values cause performance issues and hard-to-debug problems. It explains how pooling works (connection setup of TCP, TLS, and auth costs roughly 50–500ms, and each open connection consumes about 1 MB of server RAM even when idle), the borrow/execute/return/prune lifecycle governed by `maxIdleTimeMS`, and the difference between synchronous drivers (where pool size often matches the thread pool) and asynchronous drivers (where smaller pools suffice). It accounts for the two automatic monitoring connections per replica set member via the formula Total = (minPoolSize + 2) × replica members × app instances.

Practical guidance includes calculating an initial pool size from throughput and latency (Pool Size ≈ ops/sec × avg duration + a 10–20% buffer), starting conservatively when durations vary, and considering topology: pools are created per server per client, sharded clusters typically connect through mongos routers, and secondary read preferences can add a pool per member. It recommends best practices such as creating the client once and reusing it (initializing outside the handler in serverless), not closing connections manually except at shutdown, and keeping max pool size above expected concurrency. Tuned parameter tables are provided for serverless (small pools, minPoolSize 0, short idle times), long-running OLTP servers (larger pools, pre-warmed connections, fail-fast timeouts), and OLAP/analytical workloads, with each recommended value justified by the gathered context.