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:32:37 GMT
On 14 August 2012 13:39, Philippe Mouawad <philippe.mouawad@gmail.com> wrote:
> Hello,
> I think the next step should be to pool threads for start later as tests
> show clearly that live threads are below the max threads.

Depends on the test setup.
The tests that we used JMeter for at work ran for 24-48 hours, but
with the same number of threads throughout.
A pool would not help there.

In order to support pooling - i.e. re-use - of threads, a lot more of
JMeter will have to be redesigned.
Also at present test classes are cloned per thread - it would be nice
to use a single shared test plan for all threads.
However, that would mean a complete redesign of the test element
classes. I suspect even supporting pooling will have a major impact on
the test classes.

> Sebb , milamber did you measure thread creation overhead ?

Well, we know it causes issues for large numbers of threads.

At present Java threads are only created when necessary, so there's no
saving to be had.

> Thanks
> Regards
> Philippe
> On Tuesday, August 14, 2012, sebb wrote:
>
>> On 14 August 2012 11:21, Philippe Mouawad <philippe.mouawad@gmail.com<javascript:;>>
>> wrote:
>> > Hello,
>> > That was its intention :)
>> >
>> > Great news, thanks sebb for reworking it (although i liked it as it was
>> ;)
>> > ).
>> > 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 ?
>>
>> Yes, when I've finished the changes.
>>
>> > 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 <javascript:;>>
 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.
>>
>
>
> --
> Cordialement.
> Philippe Mouawad.

Mime
View raw message