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. 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!
