Re: number of threads vs number of simulated users

[sebb <se...@gmail.com>]

On 30 July 2010 18:51, Deepak Shetty <sh...@gmail.com> wrote:
> 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.
>

All good points.

Consider how much work JMeter would have to do to preserve the
variables that are local to each thread.
It would have to store them somewhere and recover them for each context switch.

Also, if the timers all happen to expire at the same time, then there
would be no way to execute all the requests unless the pool contained
as many entries as virtual users. In which case the pool is redundant.

If you want to increase the load on the server without increasing the
number of threads, reduce the wait time.

A single JMeter thread can generate much more load than a normal user.

>
> On Thu, Jul 29, 2010 at 11:53 PM, nicolas de loof
> <ni...@gmail.com>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 <sh...@gmail.com>
>>
>> > 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
>> > <ni...@gmail.com>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
>> > >
>> >
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org