jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: doc for jdbc pool configuration
Date Tue, 05 Jan 2016 22:38:45 GMT
On 5 January 2016 at 21:19, Felix Schumacher
<felix.schumacher@internetallee.de> wrote:
> Am 04.01.2016 um 16:21 schrieb sebb:
>>
>> On 2 January 2016 at 15:38, Felix Schumacher
>> <felix.schumacher@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.
>> 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.

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

>>
>>
>> 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.
>
> Regards,
>  Felix
>>
>>
>>> Regards,
>>>   Felix
>
>

Mime
View raw message