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:
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]
