On 5 January 2016 at 21:19, Felix Schumacher <felix.schumac...@internetallee.de> wrote: > 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.
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 > >
