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 >
