A better explanation for partitionCount in BoneCP

Question

From official BoneCP doc: http://jolbox.com/index.html?page=http://jolbox.com/configuration.html

partitionCount In order to reduce lock contention and thus improve performance, each incoming connection request picks off a connection from a pool that has thread-affinity, i.e. pool[threadId % partition_count]. The higher this number, the better your performance will be for the case when you have plenty of short-lived threads. Beyond a certain threshold, maintenence of these pools will start to have a negative effect on performance (and only for the case when connections on a partition start running out).

Default: 2, minimum: 1, recommended: 3-4 (but very app specific)

But it is not so clear and does not have a good example. I am running a normal web service, with 0-500 simultaneous thread. Which is a good value and why?

Answer 1

So internally BoneCP has the partition count number of pools of connections. Each time a thread tries to work with a connection, it takes thread.getId() % partitionCount and works with a connection from that pool. And you will have maxConnectionsPerPartition * partitionCount number of connections in total.

Why this has a positive effect on performance? Well to not have two threads use on the same connection simultaneously (obviously this would be bad), BoneCP has to take a lock to release or acquire the connection. But in the same time all the other threads that want to do the same, have to wait on that lock. So in a sense you can release or acquire partitionCount number of connections in parallel.

What number to set it to? I think # of cores is a good start, as you wouldn't have more work happening in parallel anyways. But other than that try to predict how many threads would be racing for connections, measure and repeat.

BTW, most of the world has been relying on c3po for over a decade and that essentially had partition count set to 1. So you can't go very wrong with it.