You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by Sonam Chauhan <so...@ce.com.au> on 2007/09/11 09:25:28 UTC
running multiple JMeter instance in parallel
Hi JMeter users -
I wanted your comments on large scale load testing approaches, and
specifically on running multiple JMeter instances running different
tests.
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.
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.
Any comments on this approach and/or the JVM parameters I'm using below?
Kind regards,
Sonam Chauhan
--
Corporate Express Australia Ltd.
Phone: +61-2-93350725, Email: sonam.chauhan@ce.com.au
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 "$@"
Re: running multiple JMeter instance in parallel
Posted by sebb <se...@gmail.com>.
On 11/09/2007, Sonam Chauhan <so...@ce.com.au> 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: sonam.chauhan@ce.com.au
>
>
>
> 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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
RE: running multiple JMeter instance in parallel
Posted by iblavins <ib...@temenos.com>.
G'day
See interspersed comments.
Ian Blavins
Contract Performance Engineer
Temenos
-----Original Message-----
From: Sonam Chauhan [mailto:sonam.chauhan@ce.com.au]
Sent: 11 September 2007 08:25
To: JMeter Users List
Subject: running multiple JMeter instance in parallel
Hi JMeter users -
I wanted your comments on large scale load testing approaches, and
specifically on running multiple JMeter instances running different
tests.
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).
>> INB I broke my test plan into two parts - a very simple test plan and a
general purpose include module invoked by the plan to do the work. The
design is intended so that I can have many test plans without having to
worry about maintaining them - all the complexity is in the include module
and I only have to maintain one copy of that. This may work for you since
the thread groups can be simple invocations of the include module. Done
right this will reduce the size, complexity, and brittleness of the test
plans.
>> INB Note that this doesn't address your 2G limit.
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.
>> INB Approaches 1 and 2 aren't mutually exclusive. Assuming that by large
scale you mean high volume and possibly also a large selection of
transactions then you will probably need approach 2 just to get the
throughput. Being Java JMeter can run on large scale server class machines
and exploit them. So if you have a sufficiently large machine you may not
need distributed testing but most people will need it for high throughput
testing. High throughput here is, somewhat unhelpfully, throughput in excess
of what one box can provide. Say a few hundred threads, depending on think
time between transactions and complexity of the test plan and sampler.
>> INB If you combine this with an include module be aware that JMeter will
automatically refresh the test plan down from the driver to the slaves but
you have to keep the include module up to date on the slaves manually.
>> INB The investment to overcome the complexity is probably worth it. Once
you have done it it will be a very long time before you need to worry about
the size of your JMeter tests again
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.
>> INB If you can do this you don't need to be scared by getting distributed
JMeter testing working
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.
Any comments on this approach and/or the JVM parameters I'm using below?
Kind regards,
Sonam Chauhan
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: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org