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 Wed, 06 Jan 2016 05:37:03 GMT


Am 5. Januar 2016 23:38:45 MEZ, schrieb sebb <sebbaz@gmail.com>:
>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.

I would use it like a csv reader on steroids and thus it wouldn't help to put it into a setup
group. 

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

It would be nicer for sure, but no pool would be even worse. 

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