[Jakarta-jmeter Wiki] Update of "JMeterAutomatedRemoteTes ting" by brettcave

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki" for change notification.

The "JMeterAutomatedRemoteTesting" page has been changed by brettcave.
http://wiki.apache.org/jakarta-jmeter/JMeterAutomatedRemoteTesting?action=diff&rev1=1&rev2=2

--------------------------------------------------

  
  = Requirements =
  This article assumes that you:
- * know the basics of JMeter
+  * know the basics of JMeter
- * have an existing test plan
+  * have an existing test plan
- * have a bit of knowledge on using variables in test plans
+  * have a bit of knowledge on using variables in test plans
- * have touched on remote testing (from GUI is fine)
+  * have touched on remote testing (from GUI is fine)
  
  = Set up =
- # In your existing test plan, make sure that any variations in testing make use of variables. For example, if running a HTTP sampler, use HTTP Request Defaults to specify a host as "${__P(targetHost)}". Other useful places for variables might include number of threads, ramp-up period or scheduler duration in a thread group, using a format of ${__P(threadgroup.threads,500)}  (The __P function is shorthand for __parameter. See the userguide for more info on using this parameter).
+  * In your existing test plan, make sure that any variations in testing make use of variables. For example, if running a HTTP sampler, use HTTP Request Defaults to specify a host as "${__P(targetHost)}". Other useful places for variables might include number of threads, ramp-up period or scheduler duration in a thread group, using a format of ${__P(threadgroup.threads,500)}  (The __P function is shorthand for __parameter. See the userguide for more info on using this parameter).
- # Save your test plan and properties file to a directory.
+  * Save your test plan and properties file to a directory.
- # Create a properties file containing all your variables. E.g. mytest.properties could contain threadgroup.threads=100, targetHost=my-target-host.com
+  * Create a properties file containing all your variables. E.g. mytest.properties could contain threadgroup.threads=100, targetHost=my-target-host.com
- # The test plan does not need Listeners, as this will be configured via parameters. This will improve performance on the testing.
+  * The test plan does not need Listeners, as this will be configured via parameters. This will improve performance on the testing.
- # Run the test mode in stand-alone mode (i.e. no remote servers):   `jmeter -n -t load_test.jmx -l load_test_report.jtl -q mytest.properties -j mytest.log`
+  * Run the test mode in stand-alone mode (i.e. no remote servers):   `jmeter -n -t load_test.jmx -l load_test_report.jtl -q mytest.properties -j mytest.log`
- # 1 small piece of functionality missing is the ability to set global variables from a property file. the "-q" parameter defines an additional property file, which is the equivalent of setting properties for the contents of the file using the -J parameter. This parameters are not global however, as would be set by the -G parameter. the following bash script (if your using Linux) would help with converting a properties file to global properties:
+  * 1 small piece of functionality missing is the ability to set global variables from a property file. the "-q" parameter defines an additional property file, which is the equivalent of setting properties for the contents of the file using the -J parameter. This parameters are not global however, as would be set by the -G parameter. the following bash script (if your using Linux) would help with converting a properties file to global properties:
  {{{
  for var in `grep -vE "^(#|$)" mytest.properties`; do
    GLOBAL_VARS="-G${var} ${GLOBAL_VARS}"
@@ -24, +24 @@

  
  This is a relatively simple bash expansion, and will break if there are any spaces in variable names or values (e.g. test.description="My Test" - the space would break the bash for loop.)
  
- # On all client machines, start up JMeter server, ensuring that firewall is not blocking connections (clients must all be on the same subnet). 
+  * On all client machines, start up JMeter server, ensuring that firewall is not blocking connections (clients must all be on the same subnet). 
- # On JMeter controller (the host initializing the test), run the test with the -R parameter (can be run using -r and specfiying hosts in jmeter properties file):
+  * On JMeter controller (the host initializing the test), run the test with the -R parameter (can be run using -r and specfiying hosts in jmeter properties file):
  `jmeter -n -t load_test.jmx -l load_test_report.jtl -q mytest.properties -j mytest.log -R remotehost1,remotehost2 ${GLOBAL_VARS}`
  
  Note that load injection to targets will be a increased as a ratio of number of threads per thread group multiplied by number of client machines.
@@ -69, +69 @@

  fi
  }}}
  
-