13

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?

Felipe
  • 16,649
  • 11
  • 68
  • 92

1 Answers1

20

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.

Mirko Adari
  • 5,083
  • 1
  • 15
  • 23
  • 8
    BoneCP author here: This explanation is perfect. Just would like to add that having more partitions also means that each partition typically has fewer connections configured (since they are divided up). If a thread attempts to hit an exhausted partition, it then spills over to try and take a connection from the other partitions so at some point it actually starts to become slower. As the javadocs say stick to around 3-4 as a maximum (no of cores is a good hint too). – wwadge Jan 28 '13 at 14:57
  • @user149789 and Mirko, so for those of us running our JVM based apps on cloud micro instances, where single cores are the norm, it sounds like partitionCount should be set to 1. Benchmarking today I was surprised to see that max used connections in my database was not 48 (have config 3 partitionCount * 16 maxConnectionsPerPartition), but rather just 16 O_o – virtualeyes Nov 05 '13 at 16:14
  • If I have to deal with parallel connections to perform at least 2 Statement operations and those connections would be ~30. Could you mind telling the partition size - Is it to be set 30? Also, if you could tell other parameters involved in setting the BoneCPDataSource? – Sanchit Feb 12 '14 at 10:12