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