jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <>
Subject Re: doc for jdbc pool configuration
Date Mon, 04 Jan 2016 18:28:53 GMT
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,

> > 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. I really think proposing the pool is useful.

> > 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.

> 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
   - 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
   - From users comments I tend to think this feature is useful and users
   are expecting it
   - 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

> > Regards,
> >  Felix

Philippe Mouawad.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message