Running 28 Jmeter instances with several threads each won't be efficient. Don't forget that you will have 28 jvm processes... Also if your server is "overloaded", Jmeter may give you wrong results. You should use several servers running one Jmeter playing different parts of your test plan. As said before, using distributed testing is not a good idea because of the network and GUI overhead.
And try to use same Xms and XmX, it's more efficient. -- Bj On 9/13/07, Sonam Chauhan <[EMAIL PROTECTED]> wrote: > > Sebb: > > > > > > 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. > > The max. amount of concurrent threads is actually 1500 threads per > instance. Each Jmeter instance runs a separate JMX that load tests a > component of the overall system. There are some instances with fewer > concurrent threads. The total number of samplers in all 28 instances > requested within 20-40 minutes is roundabout 38,000. A Perl script forks > and executes all instances, then consolidates the results. > > I ran a unified load test (28 instances) on a 3Ghz/3GB RAM Windows XP > desktop last night. The 28 test instances took up 4 GB of RAM (Windows > reported a peak total memory usage of 4.6 GB and the OS takes .5 GB) but > the tests completed. > > I wanted to say I appreciate your inputs -- you answers help a lot of > people on the list! > > Kind regards, > Sonam Chauhan > -- > Corporate Express Australia Ltd. > Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original > Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 12 September 2007 8:18 PM > To: JMeter Users List > Subject: Re: running multiple JMeter instance in parallel > > 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] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
