If you have tuned java application servers you know how difficult it is getting Thread pool sizing and other archaic java parameters correct - also consider the audience expected to use JMeter.
True if you have timers you probably would be able to achieve the same kind of throughput with a smaller thread count and pooled threads - However OS level thread pooling is far superior to any java capability so it isn't a fair comparison. I guess it comes down to I believe scaling by adding machines is far simpler to achieve than the complexity added by pooling threads. On Thu, Jul 29, 2010 at 11:53 PM, nicolas de loof <[email protected]>wrote: > This would be true with > N cores available, but the Threads allready have > to share the available ones using OS multi-threading "core-pool". There is > ALLREADY a backlog queue at OS level for our Threads to execute on limited > ressources. Using on Thread per User don't ensure concurrent requests, you > will never have more concurrenct that physical core count. Considering > "loose" concurency (i.e. active threads during a small time window), a > Thread pool would be more efficient that dedicated Threads as less context > switches would be necessary. > > On a realistic scenario we put many Timers, so our thread are moslty doing > few stufs and then call Thread.sleep. This generates many Thread context > switches with few computation. A Thread-pool would avoid (limit) the ratio > between context switches and usefull computation time. There is no way > today > to create a load with tousand threads, even if the scenario has long sleep > time (and then few computation requirements) > > I agree a Thread-pool requires tunning to set the optimal pool size. This > could be a global parameter, and set by default to physicalCoreCount * X. > > Nicolas > > 2010/7/29 Deepak Shetty <[email protected]> > > > If you want N concurrent requests , you need N threads. Any kind of > thread > > pool / execute - backlog queue mechanism would only give you an > > approximation and in addition would need you to tune the pools based on > > your > > requirements - which is probably a much harder task. > > > > > > > > > > > > On Thu, Jul 29, 2010 at 4:57 AM, nicolas de loof > > <[email protected]>wrote: > > > > > Hi, > > > > > > There's many threads on this list about simulating high number of users > > > with > > > jMeter. The main limitation seems to be the number of threads. I wonder > > why > > > jMeter uses the "1 dedicated Thread per (Virtual) User" strategy : > > > > > > - each Thread uses native memory, large number of threads requires > much > > > memory > > > - Thread context switch consumes CPU time. Switching hundred of > threads > > > on few cores over-consumes ressources. > > > > > > So, my question is : is there any plan, or any previous attempt, to use > > > thread pools in jMeter ? Typically, beeing based on Java 5, > > > java.util.concurrent provides the adequate thread pooling tools. > > > > > > Cheers, > > > Nicolas > > > > > >
