On Mon, Jan 4, 2016 at 4:21 PM, sebb <seb...@gmail.com> wrote:
> On 2 January 2016 at 15:38, Felix Schumacher
> <felix.schumac...@internetallee.de> 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)
>
> > 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.
>
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
- 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
>
--
Cordialement.
Philippe Mouawad.
