-
Notifications
You must be signed in to change notification settings - Fork 11
Connection Pooling
When you use ScalienDB's client library, it automatically maintains network connections for you. More specifically it connects to all the controllers and shard servers, and reconnects automatically when the connection is lost. This means that when you have e.g. 3 controllers and 3 shard servers, each client makes 6 network connections.
Now this might be a problem when you have a multithreaded application and you have hundreds or thousands of threads and clients in the same process. That means the number of network connections would equal 6 times the number of clients, most of them idling all the time.
Another problematic case is when the application creates a client for each request, serves the request with the client and then closes the client. If the application serves a large number of requests (e.g. thousands per second), then a lot of finished TCP connection would be waiting to be closed by the operating system, occupying resources from new connections.
Because of these reasons, the client library uses a Controller Connection Pool to reduce the number of controller connections. All clients in the same process share the controller connections, therefore the number of controller connections is equal to the number of controllers.
From version 2.2.1, there is an optional feature to use Shard Connection Pooling. By default it is turned off, so once a client makes a connection to a shard server, it will be kept alive and for each client the number of shard connections will be equal to the number of shard servers.
When turning it on (with the help of SetConnectionPoolSize function), you may specify the size of the pool. The client will maintain that number of shard connections, and it will only bind the connection to the clients for the time of a request. If you need more connections, the library will create them for you, but it won't maintain them if the number of connections exceed the size of the pool.
In order to avoid closing and creating connections under heavy load, the library may keep more connections for a limited time interval. Meanwhile a cleanup process runs periodically, and closes the idle connections.