On 12/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > Thanks for the advice Sebb! > > > > The Challenge > > > > > > I've now got to scale the testing up to about 30 concurrent JMeter > > > instances issuing a total of about 30,000 sampler requests in 30 > > > minutes. I'm hoping the same approach should work, by increasing the > > > server memory to 4 GB should help. > > > > How many concurrent threads? > > The number of concurrent threads is difficult to guess, but I'd estimate > a maximum of 1000-1500 concurrently running threads per JMeter instance > for the most intensive tests. > > I tried running the 28 JMeter load test instances on a Linux VMWare > virtual running on a beefy Quad-CPU ESX server with the following > results: >
That's about 30-50 threads per JMeter instance. It might be better to increase the number of threads and reduce the number of instances, as there will be fewer overheads. > 1) VmWare allocated 2 GB RAM: Java out of memory errors + swap usage > --------------------------------------------- > java.lang.OutOfMemoryError: unable to create new native thread > at java.lang.Thread.start(Native Method) > at > org.apache.jmeter.engine.StandardJMeterEngine.run(StandardJMeterEngine.j > av > a:387) > --------------------------------------------- > > 2) On VmWare but allocated 4 GB RAM: Java out of memory errors -- no > more native thread errors. No swap usage detected. > ---------------------------------------------- > java.lang.OutOfMemoryError > Logging Error: Unknown error writing event. > ... > ---------------------------------------------- > > 3) Real Hardware > I gave up and ran split the test instances into two group - me and a > colleague ran 15 concurrent JMeter instances each on 'real' 3GHz P4 > machines with 3GB RAM each. At this point, the tests finally ran. I > estimate that the overall memory usage (both machines) of the 28 JMeter > instances was 3-3.5 GB once the load tests got underway. I suspect the > first two failures (on ESX server) may have been caused by the > virtualization but I am yet to confirm it. > > Kind regards, > Sonam Chauhan > -- > Corporate Express Australia Ltd. > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 11 September 2007 9:09 PM > To: JMeter Users List > Subject: Re: running multiple JMeter instance in parallel > > On 11/09/2007, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > Hi JMeter users - > > > > > > > > I wanted your comments on large scale load testing approaches, and > > specifically on running multiple JMeter instances running different > > tests. > > > > JMeter is best at running multiple threads all doing the same test. > > Each thread can use different parameters - these are often used for > username/password or similar. > > However it is possible to use variables in conjunction with > conditional controllers to vary the behaviour in each thread. > > But this can quickly get difficult to set up and manage. > > > > > > Approach 1. One Big Plan > > > > One approach is to have a single humungous test plan with several > thread > > groups. The disadvantages of this are the test plan becomes big and > > brittle, and the JVM size is susceptible to the 2GB Java memory limit > > (on 32 bit systems). > > > > > > > > Approach 2. JMeter Distributed Testing > > > > A second approach is JMeter distributed testing. I've not tried it > > because I assume each JMeter instances must run the same test plan > > (i.e., the same JMX -- is this right?), plus it seemed complicated. > > > > Yes, the plan is sent to all the servers. > > It can be complicated to set up, and by default the client has to > handle all the sample responses which can place a huge load on the > network connection. > There are batch and other modes, but I've not tried these in earnest. > > > > > Approach 3. External Script runs JMeter Instances in Parallel > > > > Another approach I've had success with for several years is to run > > multiple JMeter instances in parallel. I use a Perl script that forks > > separate processes, each running JMeter with a different testcase. The > > Perl script waits for all processes to complete, then collates the > > consolidated results by parsing the JMeter XML logfiles. > > > > > > > > I use this approach to run 15 JMeter concurrent instances on a server > > with 2 GB RAM. These issue about 1500 sampler requests in 10 minutes. > > The tests all end after 10 minutes and are iterated by rerunning the > > Perl script. All this is in non-GUI mode, of course. > > > > > > > > To get the 15 tests to run on the one machine, I had to pare down > JMeter > > memory requirements (see the JVM parameters below). I basically > reduced > > HEAP memory usage down and downshifted other parameters to match. > > > > > > The Challenge > > > > I've now got to scale the testing up to about 30 concurrent JMeter > > instances issuing a total of about 30,000 sampler requests in 30 > > minutes. I'm hoping the same approach should work, by increasing the > > server memory to 4 GB should help. > > How many concurrent threads? > > > > > Any comments on this approach and/or the JVM parameters I'm using > below? > > > > See above. > > > > > > > Kind regards, > > > > Sonam Chauhan > > > > -- > > > > Corporate Express Australia Ltd. > > > > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] > > > > > > > > Modified JVM parameters set in 'bin/jmeter' > > > > > > > > HEAP="-Xms64m -Xmx256m" > > > > NEW="-XX:NewSize=32m -XX:MaxNewSize=128m" > > > > SURVIVOR="-XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=50%" > > > > TENURING="-XX:MaxTenuringThreshold=2" > > > > EVACUATION="-XX:MaxLiveObjectEvacuationRatio=20%" > > > > RMIGC="-Dsun.rmi.dgc.client.gcInterval=600000 > > -Dsun.rmi.dgc.server.gcInterval=600000" > > > > PERM="-XX:PermSize=16m -XX:MaxPermSize=64m" > > > > DEBUG="-verbose:gc -XX:+PrintTenuringDistribution" > > > > SERVER="-server" > > > > ARGS="$SERVER $HEAP $NEW $SURVIVOR $TENURING $EVACUATION $RMIGC $PERM > > $DEBUG" > > > > java -server -jar `dirname $0`/ApacheJMeter.jar "$@" > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
