jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: doc for jdbc pool configuration
Date Tue, 05 Jan 2016 21:19:42 GMT
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.
>
>> 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
  * simulating the jdbc statements of an application server, which would 
use a pool in itself
>
> 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