Created 6/12/2011 tw.cook · Updated 2/14/2017 aaron.enfield
The connection pool stores open, previously used connections for reuse so your client does not have to negotiate opening a socket for every request.
If the number of threads is fewer than 10, the upper bound should be set to R * N, where R = maximum number of simultaneous requests a client can execute and N = number of nodes in the cluster.
As the number of simultaneously executing threads increases, so does the likelihood that Secondary Access Nodes (SANs) will be distributed evenly across the cluster. The connection pool can never usefully store more than T * N open connections because no more than T requests can be executing in a client at once However, that is not a practical limit because of other factors including the client operating system's limits on open file descriptors.
For clients with a large number of threads or nodes (R
> 100, N
> 200, or R * N
> 1000), Caringo recommends a stored connection limit of 5 * T. In the SDK documentation, the recommendation is T * N with the caveat that for installations with a large number of nodes and a high thread count (approximately 100 or more), you should limit the value to 5 times the number of threads to avoid reaching the client operating system's limits on open file descriptors.
Following is a list of the client parameters that control connection pooling:
- C#: maxStoredConnections
- C++: maxStoredConnections
- Java: maxConnectionPoolSize
- Python: maxSavedConnections