An oversized pool
Enough connections to approach maxclients, which refuses new ones at the limit
app-instances: 500 pool-size: 20 maxclients: 10000
Give the instance count and pool size. The result shows the share of maxclients used, the buffer memory it costs, and what a single connection can actually sustain.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Calculate. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
Enough connections to approach maxclients, which refuses new ones at the limit
app-instances: 500 pool-size: 20 maxclients: 10000
Fewer connections, with the throughput a single one sustains
app-instances: 20 pool-size: 10 maxclients: 10000
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Redis executes on one thread, so all connections share one executor. Adding connections adds contention and buffers, not capacity.
Instead:Pipeline instead. That genuinely raises throughput.
Every connection carries input and output buffers, roughly 20 KB idle and far more under load.
Instead:Include it. Ten thousand connections is hundreds of megabytes before any data.
During a rolling deploy both old and new instances hold pools, briefly doubling connections.
Instead:Leave headroom below maxclients for the overlap.