G'day Yes, I mean the include controller.
It is not possible to pass variables in the sense of passing parameters. But from the perspective of include modules variables defined in the calling test plan are global (which is what makes this approach workable). Note that include modules can't include other modules - you can only go one level deep. (But you can invoke multiple level 1 include modules from the one test plan so you can further distribute complexity into multiple include modules). Ian Blavins Contract Performance Engineer Temenos -----Original Message----- From: Sonam Chauhan [mailto:[EMAIL PROTECTED] Sent: 11 September 2007 09:48 To: JMeter Users List Subject: RE: running multiple JMeter instance in parallel Thanks Ian - your setup is quite an eye opener. Can you describe it a bit more as I'm not clear how it works? >> 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. Were you referring to the JMeter include controller that includes other JMXs? Is it possible to pass variables between the top level test plan and the include module? Kind regards, Sonam Chauhan -- Corporate Express Australia Ltd. Phone: +61-2-93350725, Email: [EMAIL PROTECTED] -----Original Message----- From: iblavins [mailto:[EMAIL PROTECTED] Sent: Tuesday, 11 September 2007 6:21 PM To: 'JMeter Users List' Subject: RE: running multiple JMeter instance in parallel G'day See interspersed comments. Ian Blavins Contract Performance Engineer Temenos -----Original Message----- From: Sonam Chauhan [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
