jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: OnDemandThreadGroup => Delay startup option on standard ThreadGroup
Date Tue, 14 Aug 2012 14:21:30 GMT
On 14 August 2012 11:21, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> Hello,
> That was its intention :)
>
> Great news, thanks sebb for reworking it (although i liked it as it was ;)
> ).

Thanks to you for doing the initial work - that showed it was well
worth continuing.

So far I've just moved your code around a bit - basically still the
same code, but in a different class.

> And thanks both for tests.
>
> Maybe we should send a note on the changes to the original user mailing
> list message as kirk p started some tests, no ?
>
> Regards
> Philippe
>
>
> On Tuesday, August 14, 2012, Milamber wrote:
>
>>
>>
>> Le 13/08/2012 18:58, sebb a ecrit :
>>
>>> On 13 August 2012 17:07, sebb<sebbaz@gmail.com>  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
>> notification)
>>
>> 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
>>
>> Milamber
>>
>>  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!
>>>>
>>>
>>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message