You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2014/04/19 02:32:05 UTC

[DBCP] Performance vs BoneCP

Thought this might be of interest:

http://jolbox.com/benchmarks.html

Niall

Re: [DBCP] Performance vs BoneCP

Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Apr 19, 2014 at 2:16 AM, Phil Steitz <ph...@gmail.com> wrote:

> On 4/18/14, 5:32 PM, Niall Pemberton wrote:
> > Thought this might be of interest:
> >
> > http://jolbox.com/benchmarks.html
>
> I wonder what version of DBCP they were using.  Guess you have to
> dig into the source to figure that out.
>

Its a good question - and no indication when the benchmark was done. I can
see references to those going back 4 years so may be quite old.

Heres another article, using DBCP 1.4 that contradicts it:

http://www.javacodegeeks.com/2013/06/how-many-threads-does-it-take-to-fill-a-pool.html

Niall



> Phil
> >
> > Niall
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [DBCP] Performance vs BoneCP

Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Fri, 18 Apr 2014 18:16:26 -0700
schrieb Phil Steitz <ph...@gmail.com>:

> On 4/18/14, 5:32 PM, Niall Pemberton wrote:
> > Thought this might be of interest:
> >
> > http://jolbox.com/benchmarks.html
> 
> I wonder what version of DBCP they were using.  Guess you have to
> dig into the source to figure that out.

I had mentioned that on the jclarity mailing list before, I think such
kind of micro benachmarks are not really real life relevant. The
performance of a DB pool much more depends on the handling if
refreshes/validations/resets, the amount of caches and the actual
physical close and open handling (i.e. inside our outside critical
code path). Thats not measured with stubbed out db drivers (and the IO
is soo slow that optimizations in the range of microseconds is only
noise)

Of course micro benchmarks can help to find scalability issues and
allow locking/datastructure optimizations. The Bone partitions seem to
be somewhat overengeneered I feel (however it might benefit other
things like prepared statement and transaction cache locality).

Gruss
Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [DBCP] Performance vs BoneCP

Posted by Mark Thomas <ma...@apache.org>.
On 19/04/2014 02:16, Phil Steitz wrote:
> On 4/18/14, 5:32 PM, Niall Pemberton wrote:
>> Thought this might be of interest:
>>
>> http://jolbox.com/benchmarks.html
> 
> I wonder what version of DBCP they were using.  Guess you have to
> dig into the source to figure that out.

Given the comparable performance to Tomcat's JDBC pool I suspect it is
DBCP2.

The Tomcat JDBC / DBCP Pool difference are similar to those I have
observed with the Tomcat JDBC performance tests (15-20%).

Given that the results are in nanoseconds I'm not particularly
concerned. As soon as you do any useful work with a database connection
a pool overhead of 20,000ns vs. 8,000ns (or 6,000ns vs. 3,000ns) is
going to vanish into the noise.

I suspect that DBCP takes longer because it is doing more.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [DBCP] Performance vs BoneCP

Posted by Phil Steitz <ph...@gmail.com>.
On 4/18/14, 5:32 PM, Niall Pemberton wrote:
> Thought this might be of interest:
>
> http://jolbox.com/benchmarks.html

I wonder what version of DBCP they were using.  Guess you have to
dig into the source to figure that out.

Phil
>
> Niall
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org