How to Limit the Number of Connections to a Redis Enterprise Database?

Question

How to limit the number of client connections to a Redis Enterprise database?

Answer

It is possible to limit the connections in two layers of the Redis Enterprise Cluster.

Client to endpoint connections limit

Changing the number of connections between the DMC and the Application is possible, but Redis usually does not recommend this.  Limiting client connections to the endpoints can cause possible side effects. For example, if the goal is to limit to a total of 17,500 connections for a database in a 5 nodes cluster configured with all-nodes proxy policy, you will have to configure each DMC proxy to 2,500 configuring max-connections. If the cluster loses a node, the cluster will accept only 15,000 connections. However, the big concern is when you may have more than 2,500 connections per endpoint due to unbalanced traffic, which will cause a timeout. Anyhow, to limit the connections on the endpoint of a specific DB, run the following command for each DB, where N is the maximum allowed connections for each endpoint, and it must be a positive integer.

rladmin tune db db:<ID> max-connections N

The setting is per endpoint. And if several endpoints are configured for DB (all-nodes or all-master-shards proxy policy), each endpoint will be allowed to accept N connections. And this is something to keep in mind. The default value of N is zero(0), which means it is unlimited.

Endpoint to shard connections limits

Limiting the number of connections between the DMC and the shard is possible. To enable a more significant number of connections to the shards of a specific DB where N is the maximum number of connections you want to set per shard, and it must not be zero, run the following command for each specific DB:

rladmin tune db db:<ID> maxclients N

The default setting for maxclients is 10000.

Details

• Explicitly closing connections from the client side is something we don't recommend due to the overhead caused each time you open a new connection. Instead, we recommend using connection pooling.
• For commands like SUBSCRIBE a dedicated connection is opened to the shard from the proxy instead of using one from the pool of connections, unlike the other commands. Excessive usage of SUBSCRIBE can, therefore, generate overhead to the shard.