On 14 August 2012 11:21, Philippe Mouawad <[email protected]> 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<[email protected]> 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.
