jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: doc for jdbc pool configuration
Date Tue, 05 Jan 2016 10:24:07 GMT
On 4 January 2016 at 18:28, Philippe Mouawad <> wrote:
> On Mon, Jan 4, 2016 at 4:21 PM, sebb <> wrote:
>> On 2 January 2016 at 15:38, Felix Schumacher
>> <> wrote:
>> > Hi all,
>> >
>> > in our documentation there is one section about the sizing of the pool,
>> > which I like to discuss:
>> >
>> > "If you really want to use shared pooling (why?), then set the max count
>> to
>> > the same as the number of threads to ensure threads don't wait on each
>> > other."
>> >
>> > First: I think pooling is a valid option even for user-centric scenarios.
>> > Think about simulating the sql requests of an application server. In
>> such a
>> > case a pool would have been used, so why not when simulating it?
>> >
>> > So for this part, I question the part "...(why?)..." and the "really" in
>> > front of it.
>> The problem is that JMeter is then mainly testing the pool
>> implementation rather than the server.
> Not from Felix notes on bug. But read below.
>> Since the pool implementation cannot at present be replaced, that does
>> not seem to be a useful approach.
> I implemented 3 classes corresponding to 3 major pools (DBCP2, Tomcat JDBC,
> HikariCP)

However, there are lots of other pools.

>> > Second: When a pool is used (at least the dbcp2 pool) the connections
>> seem
>> > to be stored in a stack like construct. So in a uncontended load
>> situation
>> > the pool will use only a fraction of the configured size and in a
>> contended
>> > situation with really many threads it will probably overload the db.
>> That suggests that pooling should not be used by JMeter...
> I don't share your opinion.

In the context of the dbcp2 pool, it's just an observation, not an opinion.

> I really think proposing the pool is useful.

What is the use case?

>> > So all in all I would rather change the sentence to something like "If
>> you
>> > want to use shared pooling, then set the max count to something
>> sensible".
>> I think we need to document why pooling is not in general a good idea
>> for JMeter tests.
> Ok
>> However I would prefer to drop pooling support entirely unless the
>> pool implementation can be provided by the user.
> I don't share your opinion for many reasons:
>    - First there is no much remaining job to make it possible to test other
>    pool:
>    - Propose a Factory
>       - We could even embed the 2 others that were tested
>    - We improved as we dropped a deprected library, why drop now which
>    means more work for less feature

However it's not possible for the user to drop in a brand new pool
without writing a factory class.

Unlike (say) with JDBC or JSR-223, where the user can use any
implementation which has the bindings.

>    - From users comments I tend to think this feature is useful and users
>    are expecting it

Examples of such comments?

>    - Finally , we spent Felix and I some time working on this on our
>    personal time, dropping it is just a waste of our time and work, which is
>    discouraging for me to be frank with you

I have had a look at the dev list archives and the last time the issue
was discussed (August 2012) I made it clear that it only made sense to
include pooling if the implementation was configurable.
And when I raised the issue on the user list as I recall there was no
feedback saying that the feature was needed.

It's unfortunate that I was away over Xmas otherwise I would have
raised my concerns a bit earlier.

However I don't see any recent discussion on pooling, so I'm not sure
how I could have raised the issue before work was started.


I still think that JBDC pooling is unnecessary.
I have yet to see a good use case.

Also if there is a use case, that it only makes sense to provide
pooling if the implementation is completely configurable.

>> > Regards,
>> >  Felix
> --
> Cordialement.
> Philippe Mouawad.

View raw message