On 13/09/2007, Bj <[EMAIL PROTECTED]> wrote: > Running 28 Jmeter instances with several threads each won't be efficient.
I misread the original posting - each may have up to 1500 threads, so using multiple instances is sensible here. > Don't forget that you will have 28 jvm processes... > Also if your server is "overloaded", Jmeter may give you wrong results. True. > You should use several servers running one Jmeter playing different parts of > your test plan. If the server is powerful enough, then multiple JMeter instances may be better. > As said before, using distributed testing is not a good idea because of the > network and GUI overhead. Distributed testing can be run in non-GUI mode as well. > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
