Skip navigation.

Notes to self

Whatever I feel like writing

Posts tagged with "jdbc"

NanoPool Benchmark

Tuesday, 15. September 2009, 21:55:12

,

Had the opportunity to test NanoPool on an 8-core machine today. The primary purpose was to decide between two possible fixed for gh-issue #8 (a connection leak was possible with unlucky timing between a pool resize and shutting the pool down).

The test was a success overall, but a pattern emerged from the data that highlighted an undesirable behavior.



The three major humps in this chart shows three different sets of test runs, with a varying threads-to-connections factor (the X-axis number). As it turns out, the pool will show a negative throughput scaling when the number of threads accessing the pool concurrently exceeds the number of connections. The Y-axis number is the number of open/close cycles that can be squeezed through the pool in 650 milliseconds.

The reason is probably that the default ContentionHandler have a relatively high spin-rate for undersized pools. The high spin-rate will burn CPU resources that could otherwise be used by other threads to complete their work and let their connections return to the pool.

This effect is a property of NanoPools lock-less design, and I'm not sure if it is possible to deal with this behavior without compromising that principle. But one thing is certain: when you create a pool, make sure it's big enough (or use a resizing ContentionHandler).

If the pool had handled the contention ideally, the third hump would be roughly equal to, or only slightly less than, the second hump.

2 comments

JDBC Connection Pools, does the world need another?

Thursday, 2. July 2009, 22:24:28

, , ,

Over the past year or so, I have on occasion been working on a project called NanoPool. It is a JDBC 2 connection pool that exposes itself as a DataSource and is released under the Apache 2 license.

I started writing it after having read Java Concurrency in Practice, because I wanted to experiment with implement something that was both simple, concurrent and lock-free.

This experiment ended up being a JDBC connection pool implementation that is really fast at connection reuse. It is lock-free so internal dead-locks are impossible. It supports hot resizing so you can adjust the pool-size during peak-hours. It has hooks for high contention callbacks so you can be notified if your pool is too small. It has no internal threads so life-cycle management is simpler (and no thread-leaks). It has a feature-full JMX interface so management is theoretically a breeze.

With all these nice things comes a number of caveats. For instance, NanoPool will, per its design, saturate the pool and try to keep all connections open at all times. Most other pools have a maximum and minimum size that bounds how many connections will be kept open at any given time. NanoPool does not do this; it has just a pool size.

Another caveat comes by virtue of not having any internal threads. This means that the only threads that can do pool maintenance work, such as reestablishing aging connections, are the client threads that call into the pool to either claim or release connections. This may be a problem if you worry a lot about latency and standard deviation in response times. That said, I have not really checked if other pools do any better in this respect, so test & check it yourself if this is a concern.

Anyway, the question that is really on my mind is this: NanoPool is almost at 1.0 state, but does it make sense to complete it and ship it? I mean, is it really add something of value and not just noise? I think that people are extremely conservative when picking connection pools so it may be a wasted effort. On the other hand, if I go through and release it then I take on the responsibility of support and maintenance nearly regardless of the user base (although I think there will be less of this work for NanoPool than what I ended up with for Fabric).

In other words: does the world need another connection pool?

9 comments