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!
