On 13/09/2007, 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.
Sorry, my bad - I can see (now) that you wrote that originally, but I overlooked it. > 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! Thanks! > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
