jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milamber <>
Subject Re: OnDemandThreadGroup => Delay startup option on standard ThreadGroup
Date Tue, 14 Aug 2012 09:51:46 GMT

Le 13/08/2012 18:58, sebb a ecrit :
> On 13 August 2012 17:07, sebb<>  wrote:
>> I've made the changes to merge the OnDemand code back into the
>> standard ThreadGroup.
>> This means it's now trivial for users to switch between the different
>> startup types.
>> I hope I've not broken anything ...
> Seems to work OK with a simple test plan of a single Java sampler, 10 loops.
> Setting the ramp-up to the same as the thread count gives me a max of
> 3 threads concurrently.
> This runs out of memory when run without delayed start and 10000 threads.
> The same test starts fine and runs for a while with delayed start.

I've run a simple test of 2 Java sampler (with 1s sleep time), 10 loops, 
with 120000 threads and ramp-up 6000s with jmeter-trunk (on Linux 64 
bits server with 48 cores, sun jdk 6 64bits)

With delayed start, test works fine.
2400004 of sampler results

Max heap size during tests: ~2.6 GB
(jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC 
-Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt")

Average number of LWP (Light-weight process): ~500  (~threads inside the 
java process via the linux command 'ps')

Without delayed start: OutOfMemoryError: unable to create new native thread.
45176 of sampler results (test not ended, kill by me after the OOME 

Max heap size during tests: ~2.3 GB
(jmeter java opts : HEAP="-Xms8g -Xmx8g -XX:+UseConcMarkSweepGC 
-Xloggc:/tmp/gclog_`date '+20%y%m%d%H%M%S'`.txt")

Max number of LWP (Light-weight process): 30396  (~threads inside the 
java process)


Conclusion IMHO: A great behavior for JMeter and tests with a huge 
number of threads (users) with small number of individual loops per 
user, like webservice's test


> It's much quicker to stop the test as well.
> I was able to start a test with 50000 threads, but after that memory
> was a problem.
> Also, the test takes quite a long time to start up, presumably because
> of the array of JMeterThread instances.
>> There's probably still some tidying up that could be done.
>> For example, StandardJMeterEngine still creates the JMeterThread
>> instances at the start. It might be better to make the thread group
>> class responsible for handling these, so the additional objects are
>> not created until needed.
> I think that's what broke my tests with more than about 60000 threads.
> As well as deferring creation of these objects,they need to be
> released once the thread has completed.
>> BTW, my French is not up to translating the delayed_start property
>> entry - please can someone else fix that so the tests no longer fail?
>> Thanks!

View raw message