Am 04.01.2016 um 16:21 schrieb sebb:
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.
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
