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]
