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 > > >
