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