9

I just wrote a JDBC connection pool using Akka.

It uses an actor to hold a "maxPoolSize" collection of real database connections. The caller asks the pool actor for a connection and receives a Future[Connection] and the connection's status becomes 'busy' until the caller returns it to the pool on connection.close. If all the connections are busy, the new incoming request for connection will be placed on a waiting queue (also held by the pool actor). Later when a connection is returned, the waiting request will be fulfilled.

The implementation of this logic is very easy in akka, just dozens of lines of code. However when using the BoneCP Multithread Test to test the performance (i.e. the caller close the connection immediately when the Future[Connection] returned by getConnection is fulfilled. The benchmark traversed all the close request and Await for the result Future), I found that the Akka version is slower than many other connection pool implementations such as tomcat-jdbc, BoneCP or even commons DBCP.

What I have tried for tuning:

  1. splitting the pool actor into multiple ones each hold part of all the real connections
  2. tweaking some of the default-dispatcher config parameters (throughput, parallelism)

but saw no noticable improvement.

My question is :

  1. Is this a suitable use case that using akka will get better performance?
  2. If it is, how can I get similar or better benchmark data than those handcrafted-threading connection pool implementations?
  3. If it is not, why? Are there any established criteria that can help me decide when to use akka?
Alex
  • 8,093
  • 6
  • 49
  • 79
xiefei
  • 6,563
  • 2
  • 26
  • 44
  • 5
    I'm not terribly surprised. Not to doubt your development skills in the slightest, but these other libs have quite a bit more development time put into them to solve this very specific problem – joescii Sep 22 '13 at 03:44
  • would love to see answers to #3 point! – maasg Sep 22 '13 at 13:20
  • 2
    I think #3 is covered well here: http://stackoverflow.com/questions/4493001/good-use-case-for-akka – Ryan Sep 22 '13 at 18:20
  • how does the benchmark behave when all the connections are gone? is the driver locking? – Edmondo Sep 25 '13 at 13:30
  • I would search for some blocking behavior in your code. If it's just dozens of lines, maybe you can paste it here? – kopiczko Oct 01 '14 at 06:38

3 Answers3

3

To answer question #1, this is not a use case where Akka will excel in speed. You have basically taken a problem that is usually solved with a concurrent data-structure optimized for multiple readers and writers and serialized it through a single actor.

Björn Antonsson
  • 1,019
  • 6
  • 9
0

Another approach is to create Router, which will spawn several slave Actors, each representing a single connection.

But be aware that there could be potential race conditions.

Also, what version of Scala and Akka you are using?

alatar
  • 46
  • 2
0

Akka might be a good choice for highly parallel computations while a JDBC connection pool is not a good example for highly parallel computations.

kocka
  • 657
  • 6
  • 14
  • elcome to stackoverflow!This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. Please read the guidelines for good answers: http://stackoverflow.com/questions/how-to-answer. – bitoiu Jun 11 '14 at 16:03