They are suitable for production use for protecting your Cassandra server, not the clients. The clients likely will experience an error when the limit is reached, and it needs to handle that error appropriately.

What you really want to do probably are:

1. change the client's behaviour, limit the number of servers it connects to concurrently. The client can close connections not in use, and/or only connect to a subset of servers (note: affects token-aware routing).

2. after made the above change, if the number of connections is still an issue, horizontally scale up your Cassandra cluster to handle the peak number of connections. More nodes means less connections to each node.

On 29/02/2024 10:50, Naman kaushik wrote:

Hello Cassandra Community,

We've been experiencing occasional spikes in the number of client connections to our Cassandra cluster, particularly during high-volume API request periods. We're using persistent connections, and we've noticed that the number of connections can increase significantly during these spikes.

We're considering using the following Cassandra parameters to manage concurrent client connections:

*native_transport_max_concurrent_connections*: This parameter sets the maximum number of concurrent client connections allowed by the native transport protocol. Currently, it's set to -1, indicating no limit.

*native_transport_max_concurrent_connections_per_ip*: This parameter sets the maximum number of concurrent client connections allowed per source IP address. Like the previous parameter, it's also set to -1.

We're thinking of using these parameters to limit the maximum number of connections from a single IP address, especially to prevent overwhelming the database during spikes in API requests that should be handled by our SOA team exclusively.

Are these parameters suitable for production use, and would implementing restrictions on concurrent connections per IP be considered a good practice in managing Cassandra clusters?

Any insights or recommendations would be greatly appreciated.

Thank you!


Reply via email to