Connection Pool Configuration

As we have discussed earlier, Riak is a distributed database. A live Riak system consists of a number of independent Riak Nodes that work together to serve data to clients. The set of all nodes that work together is called a Riak Cluster. Within the cluster there are no special roles; all nodes are equal. When a client wants to make a request to Riak, it can send this request to any one of the nodes in the cluster and Riak will handle the request exactly the same. When a client sends a request to a node, that node takes on the responsibility of administrating that request. This means that the node dispatches and distributes the request within the cluster and gathers the result before responding to the client with the result. This means that while the request is being executed in the cluster, the initial node uses more CPU and memory than the other nodes that participate in the request. If the client were to send all of its requests to the same node every time, that node would experience a heavier load than the other nodes in the cluster. For this reason, you can configure the uGameDB client with any number of nodes and it will automatically balance the load among them when making requests. The uGameDB client sets up a connection pool to each configured Riak node. The connection pool consists of a number of TCP connections to the node that can be used to send requests. The motive for using several connections to each node is to be able to perform database operations in parallel.

Number of sockets per pool

If you have just one pool to one Riak node, the number of sockets in the pool is the maximum number of Riak commands that can be executed in parallel. Therefore the number of sockets in the pool can be an important number to trim for the game server’s performance. If you have too few sockets, for example just one, the game server will execute database reads and writes in a serial manner, which might be too slow for your gameplay. On the other hand, if your number of sockets is too large, you will use up a lot of memory unncessarily. The optimal number of sockets per pool depends on gameplay, amount of data in the database, hardware capacity, and more, but a good default value to start with is 10. If you have three Riak nodes, then every game server will have 3 pools, 10 sockets in each and thus it will be possible to run 30 database commands in parallel. Use a load testing tool if you need to make sure this is sufficient for your game servers.

Number of pools per game server

If you have a Riak cluster with three nodes it is smart to configure three connection pools in every game server. Configure one connection pool per Riak node. This is smart because uGameDB does load balancing automatically in a round-robin manner. If you send three “Get” operations to the uGameDB API, they will be sent to one Riak node each. Just add the utility script uGameDBConnection to any game object in the server’s scene to make the game server connect to Riak at startup. The figure below show the inspector view of this component. It is easy to configure the number of nodes, the IP address for each node and the Riak PCB port number.

Failover scenarios

If one Riak nodes fails to respond, uGameDB will remove it from the list of available nodes and the read and write commands will be sent to the other database nodes. This makes it possible to stop one Riak node for maintenance (e.g. for upgrading the hardware) without interrupting the game servers at all. If there is a critical failure in one of the nodes or in the network between them, the same thing happens. This is a powerful feature that makes uGameDB very robust and fail safe. As long as there are enough nodes to serve your requests in an acceptable manner, nodes can go down without breaking the game server. When a node comes back online, uGameDB will detect it and add the node to the list of available nodes used by the load-balancing algorithm. uGameDB has a running background thread that checks if nodes are up or down with a configurable interval.

Number of pools versus Riak nodes

If you have a large database cluster with lots of nodes, it is not mandatory to make a connection pool for every node in every game server - this would just be difficult to configure and maintain. Can spread out a few connection pools from each game server among all the available nodes. Then you have the lowest risk of having one game server lose all of its connected nodes due to failure.