On Tuesday, January 5, 2016, sebb <[email protected]> wrote: > On 5 January 2016 at 21:19, Felix Schumacher > <[email protected] <javascript:;>> wrote: > > Am 04.01.2016 um 16:21 schrieb sebb: > >> > >> On 2 January 2016 at 15:38, Felix Schumacher > >> <[email protected] <javascript:;>> 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.
It can be more complex or require more 3rd party binaries. Having the pool and multithreading the work can be interesting > > * 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. you will be always limited by proprietary pools of comercial servers. But if we add the 3 tested we cover: - play2 - tomcat (jdbc and dbcp) I think it's interesting enough. Providing a factory to plug others would allow testing the ones we don't want to distribute (c3p0...) or the commercial ones. > >> > >> > >> 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. I agree > > > > Regards, > > Felix > >> > >> > >>> Regards, > >>> Felix > > > > > -- Cordialement. Philippe Mouawad.
