jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: doc for jdbc pool configuration
Date Tue, 05 Jan 2016 23:06:15 GMT
On Tuesday, January 5, 2016, sebb <sebbaz@gmail.com> wrote:

> On 5 January 2016 at 21:19, Felix Schumacher
> <felix.schumacher@internetallee.de <javascript:;>> wrote:
> > Am 04.01.2016 um 16:21 schrieb sebb:
> >>
> >> On 2 January 2016 at 15:38, Felix Schumacher
> >> <felix.schumacher@internetallee.de <javascript:;>> 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.
> >> Since the pool implementation cannot at present be replaced, that does
> >> not seem to be a useful approach.
> >
> > In my observations the actual pooling part in jmeter is rather low
> overhead
> > compared to jdbc or other jmeter code, so I think the pooling
> implementation
> > is not that relevant compared to the fact to use a pool.
> >
> > I have done some totally unscientific tests using a local postgresql
> > instance with a little database and a simple select (with two joins, so a
> > bit more involved than just "select 1"). The laptop had four cores and
> > enough memory not to swap.
> >
> > For 600 threads 100 loops and different pool sizes I got the following
> > results:
> >
> > pool size 0 (every thread has its own pool)
> > summary = 120000 in 00:02:28 =  811,0/s Avg:   463 Min:     2 Max: 17700
> > Err:     0 (0,00%)
> > memory went quite low and load went up to 400
> >
> > pool size 64
> > summary = 120000 in 00:02:22 =  844,8/s Avg:   638 Min:     2 Max: 18797
> > Err:     0 (0,00%)
> >
> > pool size 32
> > summary = 120000 in 00:02:22 =  843,7/s Avg:   633 Min:     2 Max: 15679
> > Err:     0 (0,00%)
> >
> > pool size 16
> > summary = 120000 in 00:02:23 =  840,9/s Avg:   653 Min:     2 Max: 13607
> > Err:     0 (0,00%)
> >
> > pool size 8
> > summary = 120000 in 00:02:22 =  842,8/s Avg:   653 Min:     2 Max: 16502
> > Err:     0 (0,00%)
> >
> > pool size 4
> > summary = 120000 in 00:02:22 =  843,7/s Avg:   674 Min:     2 Max: 8114
> Err:
> > 0 (0,00%)
> >
> > pool size 2
> > summary = 120000 in 00:02:49 =  709,6/s Avg:   801 Min:     2 Max: 9215
> Err:
> > 0 (0,00%)
> >
> > My interpretation is: a pool helps to keep the db happy, but it has to be
> > sized appropriately (whatever that means)
> >
> > I think the result would be even more in favour of the pool, if the db
> would
> > not have fitted in RAM and would induce a io bottleneck by the parallel
> db
> > processes. Plus, I had to configure my postgresql instance to allow more
> > than 100 simultaneous connections.
>
> I don't doubt that using a pool helps.
>
> >>
> >>
> >>> 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...
> >
> > Why? When we are not using a pool, JMeter will overload the db also.
> >>
> >>
> >>> 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.
> >
> > I would rather document why and when pooling should be used.
> >
> > I have at least two use cases where pooling is useful:
> >  * using the jdbc sampler to fill variables which are then used further
> in
> > the test
>
> That is possibly a valid use case, however this should be done in a
> setUp ThreadGroup, so performance is not so much of an issue.
> Besides, if the setup takes so long that it needs a pool, it should
> probably be done using a database bulk-load facility.

It can be more complex or require more 3rd party binaries.
Having the pool and multithreading the work can be  interesting

> >  * simulating the jdbc statements of an application server, which would
> use
> > a pool in itself
>
> In which case, it is important to be able to use the same pool as the
> application server.


you will be always limited by proprietary pools of comercial servers.

But if we add the 3 tested we cover:
- play2
- tomcat (jdbc and dbcp)

I think it's interesting enough.
Providing a factory to plug others would allow testing the ones we don't
want to distribute (c3p0...) or the  commercial ones.


> >>
> >>
> >> However I would prefer to drop pooling support entirely unless the
> >> pool implementation can be provided by the user.
> >
> > The option of making the pool implementation configurable is open to us.

I agree

> >
> > Regards,
> >  Felix
> >>
> >>
> >>> Regards,
> >>>   Felix
> >
> >
>


-- 
Cordialement.
Philippe Mouawad.

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