🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Connection Pool Sizing, Measured: Why 48 Connections Beat 400
A benchmark sweep of a PostgreSQL instance from 1 to 400 connections shows throughput peaking at 48 connections (18,039 tps) and dropping 37% by 400 connections, while average latency multiplied 13x. The piece explains why connections are OS processes competing for cores rather than free capacity, tests the Universal Scalability Law fit (R²=0.94, predicted optimum 45.1), evaluates the (cores×2)+spindles formula (predicts 9, far off the measured 48), and finds that synchronous_commit=off raises throughput but does not shift the peak. It closes with practical guidance: watch queue depth (cl_waiting in PgBouncer, pending-threads in HikariCP) rather than connection count, account for instances × pool size multiplication, and use transaction pooling or RDS Proxy for Lambda to avoid connection exhaustion.
