G'day The number of threads that JMeter can run simultaneously depends on a number of variables.
One (as you have discovered) is the amount of memory allocated to JMeter. This has to be sufficient to provide memory for the running threads which run within JMeter. The memory used by a thread depends on the content of your test plan. So if you are running out of memory (which is what your error message is saying) you can either increase the amount of memory allocated to JMeter, or run a simpler test plan, or run less threads, or use JMeter server. If you run JMeter server on n boxes then you get n lots of JMeter memory to support the running threads. To increase the memory for JMeter use the JMeter heap execution parameter (see the JMeter.bat procedure). Note that as you approach the limits of JMeter memory JMeter (or, strictly, the JVM) will spend more and more of its resources garbage collecting. For performance you want to avoid this so ideally JMeter's memory allocation should be sufficiently generous that garbage collection becomes a minor background drain on resources. When you get past your memory problem I wouldn't be surprised if your test still doesn't run very well. 5,000 threads is a lot to handle. If you haven't put pacing into the test plan (ie some kind of delay or timer to limit the speed at which each thread sends its work) then you may well overwhelm either the JMeter host or the system under test. Again how many threads you will get depends on the resources consumed by each thread, both on the JMeter host and on the system under test. This is turn is dependent on the content of your test plan and the nature of your samplers and the target application. Considering only the JMeter resource consumption, if you find that the JMeter host can't handle the number of threads you want the resolution is the same as for running out of memory: more of the resource, simpler test plan, less threads, or JMeter server. (Some test plan elements are known to be resource consumptive - see the User Manual.) However when a run doesn't give decent results it may not be trivial to determine whether it is the JMeter host that can't handle the workload or the system under test. Generally start at a load (number of threads) that both JMeter and the system under test can handle and gives good results. Then gradually work up to the target load, observing the behaviour of the JMeter host and the system under test. Then when the run breaks you'll have an idea of where it broke. Ian Blavins Contract Performance Engineer Temenos -----Original Message----- From: Sonam Chauhan [mailto:[EMAIL PROTECTED] Sent: 09 May 2007 07:46 To: JMeter Users List Subject: maximum number of threads per JMeter instance Hi - Can someone point me to documentation on the maximum number of threads a single JMeter instance can handle? (I cannot find this information on Google or the wiki.) I have a problem with a testcase that has a large number of threads - it has 2 thread groups with 2000 and 5000 threads each. On a Windows XP SP2 system with 2GB of RAM, java.exe grows to about 350MB before throwing this exception: ------------------------- Exception in thread "Thread-1" java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method) at java.lang.Thread.start(Thread.java:574) at org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.j ava:387) at java.lang.Thread.run(Thread.java:595) ------------------------- The JMeter version is 2.1.1 and the Java version is "1.5.0_10" ------------------------- Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_10-b03) Java HotSpot(TM) Client VM (build 1.5.0_10-b03, mixed mode) ------------------------- I tried tweaking two JMeter run script settings: HEAP and NEW. I started small, and increased the numbers proportionally up until Xmx=1024m but it was little use - the more I increased HEAP size, the faster I got the outOfMemory errors. I also came across some interesting information here about the maximum number of threads per process: http://blogs.msdn.com/oldnewthing/archive/2005/07/29/444912.aspx I tried using '-Xss128k' to reduce stack size per Java thread, but that did not help either. Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] This email (and any attachments) contains confidential information, and is intended only for the named recipient. Distribution or copying of this email by anyone other than the named recipient is prohibited. If you are not the named or intended recipient, please notify TEMENOS or the sender immediately and permanently destroy this email (and any attachments) and all copies of it. No member of TEMENOS Group AG or any of its associated or affiliated companies is liable for any errors or omissions in the content or transmission of this email. Any opinions contained in this email are solely those of the author and, unless clearly indicated otherwise in writing, are not endorsed by any member of TEMENOS Group AG or any of its associated and affiliated companies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
