jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fschumac...@apache.org
Subject svn commit: r1670761 - in /jmeter/trunk/xdocs/usermanual: best-practices.xml remote-test.xml
Date Wed, 01 Apr 2015 19:44:13 GMT
Author: fschumacher
Date: Wed Apr  1 19:44:12 2015
New Revision: 1670761

URL: http://svn.apache.org/r1670761
Log:
More code markup changes

Modified:
    jmeter/trunk/xdocs/usermanual/best-practices.xml
    jmeter/trunk/xdocs/usermanual/remote-test.xml

Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1670761&r1=1670760&r2=1670761&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
+++ jmeter/trunk/xdocs/usermanual/best-practices.xml Wed Apr  1 19:44:12 2015
@@ -73,9 +73,9 @@ recorder. The most important thing to do
 interested in.  For instance, there's no point in recording image requests (JMeter can
 be instructed to download all images on a page - see <complink name="HTTP Request"/>).
 These will just clutter your test plan.  Most likely, there is an extension all your files
-share, such as .jsp, .asp, .php, .html or the like. These you should "include" by
-entering ".*\.jsp" as an "Include Pattern". </p>
-<p>Alternatively, you can exclude images by entering ".*\.gif" as an "Exclude Pattern".
+share, such as <code>.jsp</code>, <code>.asp</code>, <code>.php</code>,
<code>.html</code> or the like.
+These you should "<code>include</code>" by entering "<code>.*\.jsp</code>"
as an "Include Pattern". </p>
+<p>Alternatively, you can exclude images by entering "<code>.*\.gif</code>"
as an "Exclude Pattern".
 Depending on your application, this may or may not be a better way to go.  You may
 also have to exclude stylesheets, javascript files, and other included files.  Test
 out your settings to verify you are recording what you want, and then erase and start
@@ -98,9 +98,9 @@ certain common elements from the recorde
 <a href="functions.html">user-defined variables</a> at the Test Plan level or
in
 <complink name="User Defined Variables"/> elements, you can have JMeter automatically
 replace values in you recorded samples.  For instance, if you are testing an app on
-server "xxx.example.com", then you can define a variable called "server" with the value of
-"xxx.example.com", and anyplace that value is found in your recorded samples will be replaced
-with "${server}".
+server "<code>xxx.example.com</code>", then you can define a variable called
"<code>server</code>" with the value of
+"<code>xxx.example.com</code>", and anyplace that value is found in your recorded
samples will be replaced
+with "<code>${server}</code>".
 
 <note>Please note that matching is case-sensitive.</note>
 
@@ -108,11 +108,11 @@ with "${server}".
 <p>
 If JMeter does not record any samples, check that the browser really is using the proxy.
 If the browser works OK even if JMeter is not running, then the browser cannot be using the
proxy.
-Some browsers ignore proxy settings for localhost or 127.0.0.1; try using the local hostname
or IP instead.
+Some browsers ignore proxy settings for <code>localhost</code> or <code>127.0.0.1</code>;
try using the local hostname or IP instead.
 </p>
 <p>
 The error "unknown_ca" probably means that you are trying to record HTTPS, and the browser
has not accepted the
-JMeter Proxy server certificate. 
+JMeter Proxy server certificate.
 </p>
 <!--TODO: Describe how to use this to record against one server[name]
 and run against another. Actually, this particular example may be beter for the HTTP Request
Defaults...
@@ -134,14 +134,14 @@ Put this in the same directory as your t
 </li>
 <li>
 Add a CSV DataSet configuration element to the test plan.
-Name the variables USER and PASS.
+Name the variables <code>USER</code> and <code>PASS</code>.
 </li>
 <li>
-Replace the login name with ${USER} and the password with ${PASS} on the appropriate
+Replace the login name with <code>${USER}</code> and the password with <code>${PASS}</code>
on the appropriate
 samplers
 </li>
 </ul>
-<p>The CSV Data Set element will read a new line for each thread. 
+<p>The CSV Data Set element will read a new line for each thread.
 </p>
 </section>
 
@@ -150,11 +150,11 @@ samplers
 Some suggestions on reducing resource usage.
 </p>
 <ul>
-<li>Use non-GUI mode: jmeter -n -t test.jmx -l test.jtl</li>
-<li>Use as few Listeners as possible; if using the -l flag as above they can all be
deleted or disabled.</li>
+<li>Use non-GUI mode: <code>jmeter -n -t test.jmx -l test.jtl</code></li>
+<li>Use as few Listeners as possible; if using the <code>-l</code> flag
as above they can all be deleted or disabled.</li>
 <li>Don't use "View Results Tree" or "View Results in Table" listeners during the load
test, use them only during scripting phase to debug your scripts.</li>
-<li>Rather than using lots of similar samplers, 
-use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample. 
+<li>Rather than using lots of similar samplers,
+use the same sampler in a loop, and use variables (CSV Data Set) to vary the sample.
 [The Include Controller does not help here, as it adds all the test elements in the file
to the test plan.]
 </li>
 <li>Don't use functional mode</li>
@@ -165,7 +165,7 @@ use the same sampler in a loop, and use
 </ul>
 <p>
 If your test needs large amounts of data - particularly if it needs to be randomised - create
the test data in a file
-that can be read with CSV Dataset. This avoids wasting resources at run-time. 
+that can be read with CSV Dataset. This avoids wasting resources at run-time.
 </p>
 </section>
 
@@ -180,33 +180,33 @@ These can provide unrestricted access to
 <b>Do not enable the server unless the ports are protected against access, e.g. by
a firewall.</b>
 </note>
 <p>
-If you do wish to use the server, define the following in jmeter.properties:
+If you do wish to use the server, define the following in <code>jmeter.properties</code>:
 </p>
-<pre>
+<source>
 beanshell.server.port=9000
 beanshell.server.file=../extras/startup.bsh
-</pre>
+</source>
 <p>
-In the above example, the server will be started, and will listen on ports 9000 and 9001.
-Port 9000 will be used for http access. Port 9001 will be used for telnet access.
-The startup.bsh file will be processed by the server, and can be used to define various functions
and set up variables.
+In the above example, the server will be started, and will listen on ports <code>9000</code>
and <code>9001</code>.
+Port <code>9000</code> will be used for http access. Port <code>9001</code>
will be used for telnet access.
+The <code>startup.bsh</code> file will be processed by the server, and can be
used to define various functions and set up variables.
 The startup file defines methods for setting and printing JMeter and system properties.
 This is what you should see in the JMeter console:
 </p>
-<pre>
+<source>
 Startup script running
 Startup script completed
 Httpd started on port: 9000
 Sessiond started on port: 9001
-</pre>
+</source>
 <p>
-There is a sample script (extras/remote.bsh) you can use to test the server.
+There is a sample script (<code>extras/remote.bsh</code>) you can use to test
the server.
 [Have a look at it to see how it works.]
 <br/>
 When starting it in the JMeter bin directory
 (adjust paths as necessary if running from elsewhere)
 the output should look like:
-<pre>
+<source>
 $ java -jar ../lib/bshclient.jar localhost 9000 ../extras/remote.bsh
 Connecting to BSH server on localhost:9000
 Reading responses from server ...
@@ -229,34 +229,34 @@ Setting property 'EXAMPLE' to '9'.
 EXAMPLE = 9
 remote.bsh ended
 bsh % ... disconnected from server.
-</pre>
+</source>
 </p>
 <p>
 As a practical example, assume you have a long-running JMeter test running in non-GUI mode,
-and you want to vary the throughput at various times during the test. 
+and you want to vary the throughput at various times during the test.
 The test-plan includes a Constant Throughput Timer which is defined in terms of a property,
-e.g. ${__P(throughput)}. 
+e.g. <code>${__P(throughput)}</code>.
 The following BeanShell commands could be used to change the test:
 </p>
-<pre>
+<source>
 printprop("throughput");
-curr=Integer.decode(args[0]); // Start value
-inc=Integer.decode(args[1]);  // Increment
-end=Integer.decode(args[2]);  // Final value
-secs=Integer.decode(args[3]); // Wait between changes
-while(curr &lt;= end){
+curr = Integer.decode(args[0]);  // Start value
+inc  = Integer.decode(args[1]);  // Increment
+end  = Integer.decode(args[2]);  // Final value
+secs = Integer.decode(args[3]);  // Wait between changes
+while(curr &lt;= end) {
   setprop("throughput",curr.toString()); // Needs to be a string here
   Thread.sleep(secs*1000);
   curr += inc;
 }
 printprop("throughput");
-</pre>
-<p>The script can be stored in a file (throughput.bsh, say), and sent to the server
using bshclient.jar.
+</source>
+<p>The script can be stored in a file (<code>throughput.bsh</code>, say),
and sent to the server using <code>bshclient.jar</code>.
 For example:
 </p>
-<pre>
+<source>
 java -jar ../lib/bshclient.jar localhost 9000 throughput.bsh 70 5 100 60
-</pre>
+</source>
 </section>
 
 <section name="&sect-num;.9 BeanShell scripting" anchor="bsh_scripting">
@@ -265,7 +265,7 @@ java -jar ../lib/bshclient.jar localhost
 Each BeanShell test element has its own copy of the interpreter (for each thread).
 If the test element is repeatedly called, e.g. within a loop, then the interpreter is retained
 between invocations unless the "Reset bsh.Interpreter before each call" option is selected.
-For intensive load testing, it is recommended to use a JSR223 scripting language whose ScriptingEngine
implements Compilable, 
+For intensive load testing, it is recommended to use a JSR223 scripting language whose ScriptingEngine
implements Compilable,
 see JSR223 section below for more details.
 </p>
 <p>
@@ -273,48 +273,52 @@ Some long-running tests may cause the in
 </p>
 <p>
 You can test BeanShell scripts outside JMeter by using the command-line interpreter:
-<pre>
+<source>
 $ java -cp bsh-xxx.jar[;other jars as needed] bsh.Interperter file.bsh [parameters]
+</source>
 or
+<source>
 $ java -cp bsh-xxx.jar bsh.Interperter
 bsh% source("file.bsh");
 bsh% exit(); // or use EOF key (e.g. ^Z or ^D)
-</pre>
+</source>
 </p>
 </subsection>
 <subsection name="&sect-num;.9.2 Sharing Variables" anchor="bsh_variables">
 <p>
 Variables can be defined in startup (initialisation) scripts.
-These will be retained across invocations of the test element, unless the reset option is
used.\
+These will be retained across invocations of the test element, unless the reset option is
used.
 </p>
 <p>
-Scripts can also access JMeter variables using the get() and put() methods of the "vars"
variable,
-for example: <code>vars.get("HOST"); vars.put("MSG","Successful");</code>.
-The get() and put() methods only support variables with String values,
-but there are also getObject() and putObject() methods which can be used for arbitrary objects.
+Scripts can also access JMeter variables using the <code>get()</code> and <code>put()</code>
methods of the "<code>vars</code>" variable,
+for example:
+<source>vars.get("HOST");
+vars.put("MSG","Successful");</source>
+The <code>get()</code> and <code>put()</code> methods only support
variables with String values,
+but there are also <code>getObject()</code> and <code>putObject()</code>
methods which can be used for arbitrary objects.
 JMeter variables are local to a thread, but can be used by all test elements (not just Beanshell).
 </p>
 <p>
 If you need to share variables between threads, then JMeter properties can be used:
-<pre>
+<source>
 import org.apache.jmeter.util.JMeterUtils;
-String value=JMeterUtils.getPropDefault("name","");
+String value = JMeterUtils.getPropDefault("name","");
 JMeterUtils.setProperty("name", "value");
-</pre>
-The sample .bshrc files contain sample definitions of getprop() and setprop() methods.
+</source>
+The sample <code>.bshrc</code> files contain sample definitions of <code>getprop()</code>
and <code>setprop()</code> methods.
 </p>
 <p>
-Another possible method of sharing variables is to use the "bsh.shared" shared namespace.
+Another possible method of sharing variables is to use the "<code>bsh.shared</code>"
shared namespace.
 For example:
-<pre>
+<source>
 if (bsh.shared.myObj == void){
     // not yet defined, so create it:
-    myObj=new AnyObject();
+    myObj = new AnyObject();
 }
 bsh.shared.myObj.process();
-</pre>
+</source>
 Rather than creating the object in the test element, it can be created in the startup file
-defined by the JMeter property "beanshell.init.file". This is only processed once.
+defined by the JMeter property "<code>beanshell.init.file</code>". This is only
processed once.
 </p>
 </subsection>
 </section>
@@ -322,7 +326,7 @@ defined by the JMeter property "beanshel
 <section name="&sect-num;.10 Developing script functions in BeanShell, Javascript
or Jexl etc." anchor="developing_scripts">
 <p>
 It's quite hard to write and test scripts as functions.
-However, JMeter has the JSR223, BSF (and BeanShell) samplers which can be used instead. 

+However, JMeter has the JSR223, BSF (and BeanShell) samplers which can be used instead.
 </p>
 <p>
 Create a simple Test Plan containing the JSR223 or BSF Sampler and Tree View Listener.
@@ -333,9 +337,9 @@ Also the result of running the script wi
 <p>
 Once the script is working properly, it can be stored as a variable on the Test Plan.
 The script variable can then be used to create the function call.
-For example, suppose a BeanShell script is stored in the variable RANDOM_NAME.
+For example, suppose a BeanShell script is stored in the variable <code>RANDOM_NAME</code>.
 The function call can then be coded as <code>${__BeanShell(${RANDOM_NAME})}</code>.
-There is no need to escape any commas in the script, 
+There is no need to escape any commas in the script,
 because the function call is parsed before the variable's value is interpolated.
 </p>
 </section>
@@ -347,35 +351,35 @@ For example, changing the number of thre
 </p>
 <p>
 One way to do this is to define a set of variables on the Test Plan, and then use those variables
in the test elements.
-For example, one could define the variable LOOPS=10, and refer to that in the Thread Group
as ${LOOPS}. 
-To run the test with 20 loops, just change the value of the LOOPS variable on the Test Plan.
+For example, one could define the variable <code>LOOPS=10</code>, and refer to
that in the Thread Group as <code>${LOOPS}</code>.
+To run the test with 20 loops, just change the value of the <code>LOOPS</code>
variable on the Test Plan.
 </p>
 <p>
 This quickly becomes tedious if you want to run lots of tests in non-GUI mode.
 One solution to this is to define the Test Plan variable in terms of a property,
 for example <code>LOOPS=${__P(loops,10))}</code>.
-This uses the value of the property "loops", defaulting to 10 if the property is not found.
-The "loops" property can then be defined on the JMeter command-line:
-<code>jmeter ... -Jloops=12 ...</code>.
-If there are a lot of properties that need to be changed together, 
+This uses the value of the property "<code>loops</code>", defaulting to <code>10</code>
if the property is not found.
+The "<code>loops</code>" property can then be defined on the JMeter command-line:
+<source>jmeter ... -Jloops=12 ...</source>
+If there are a lot of properties that need to be changed together,
 then one way to achieve this is to use a set of property files.
-The appropriate property file can be passed in to JMeter using the -q command-line option.
+The appropriate property file can be passed in to JMeter using the <code>-q</code>
command-line option.
 </p>
 </section>
 
 <section name="&sect-num;.12 JSR223 Elements" anchor="jsr223">
 <p>
 For intensive load testing, the recommended scripting language is one whose ScriptingEngine
implements the Compilable interface.
-Groovy scripting engine implements Compilable. However neither Beanshell nor Javascript do
so as of release date of JMeter 2.13, so it is 
-recommended to avoid them for intensive load testing. 
+Groovy scripting engine implements Compilable. However neither Beanshell nor Javascript do
so as of release date of JMeter 2.13, so it is
+recommended to avoid them for intensive load testing.
 [Note: Beanshell implements the Compilable interface but it has not been coded - the method
just throws an Exception.
 JMeter has an explicit work-round for this bug.]
 
 When using JSR 223 elements, always set caching key to a unique value to ensure the script
compilation is cached if underlying language supports it.
-Ensure the script does not use any variable using ${varName} as caching would take only first
value of ${varName}. Instead use :
-<code>
+Ensure the script does not use any variable using <code>${varName}</code> as
caching would take only first value of <code>${varName}</code>. Instead use :
+<source>
 vars.get("varName")
-</code>
+</source>
 </p>
 <p>
 You can also pass them as Parameters to the script and use them this way.
@@ -391,17 +395,19 @@ If the value is not known until the test
 <ul>
 <li>Store the variable as a property - properties are global to the JMeter instance</li>
 <li>Write variables to a file and re-read them.</li>
-<li>Use the bsh.shared namespace - see <a href="#bsh_variables">above</a></li>
+<li>Use the <code>bsh.shared</code> namespace - see <a href="#bsh_variables">above</a></li>
 <li>Write your own Java classes</li>
 </ul>
 </p>
 </section>
 
 <section name="&sect-num;.14 Managing properties" anchor="properties">
-<p>When you need to modify jmeter properties, ensure you don't modify jmeter.properties
file, <b>instead copy the property from jmeter.properties and modify its value in user.properties
file</b>.<br/>
+<p>When you need to modify jmeter properties, ensure you don't modify <code>jmeter.properties</code>
file,
+<b>instead copy the property from <code>jmeter.properties</code> and modify
its value in <code>user.properties</code> file</b>.<br/>
 Doing so will ease you migration to the next version of JMeter. <br/>
-Note that in the documentation jmeter.properties is frequently mentioned but this should
be understood as "Copy from jmeter.properties to user.properties the property you want to
modify and do so in the latter file".</p>
-<note>user.properties file superseeds the properties defined in jmeter.properties</note>
+Note that in the documentation <code>jmeter.properties</code> is frequently mentioned
but this should be understood as
+"Copy from jmeter.properties to user.properties the property you want to modify and do so
in the latter file".</p>
+<note><code>user.properties</code> file superseeds the properties defined
in <code>jmeter.properties</code></note>
 </section>
 
 </body>

Modified: jmeter/trunk/xdocs/usermanual/remote-test.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/remote-test.xml?rev=1670761&r1=1670760&r2=1670761&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/remote-test.xml (original)
+++ jmeter/trunk/xdocs/usermanual/remote-test.xml Wed Apr  1 19:44:12 2015
@@ -99,10 +99,10 @@ If this is non-zero, it will be used as
 <p>Edit the properties file <i>on the controlling JMeter machine</i>. 
In <code>JMETER_HOME/bin/jmeter.properties</code>,
 find the property named, "<code>remote_hosts</code>", and
 add the value of your running JMeter server's IP address.  Multiple such servers can be added,
comma-delimited.</p>
-<p>Note that you can use the -R <a href="get-started.html#override">command line
option</a>
+<p>Note that you can use the <code>-R</code> <a href="get-started.html#override">command
line option</a>
 instead to specify the remote host(s) to use. This has the same effect as using <code>-r</code>
and <code>-Jremote_hosts={serverlist}</code>.
     E.g. </p><source>jmeter -Rhost1,127.0.0.1,host2</source>
-<p>If you define the JMeter property server.exitaftertest=true, then the server will
exit after it runs a single test.
+<p>If you define the JMeter property <code>server.exitaftertest=true</code>,
then the server will exit after it runs a single test.
 See also the <code>-X</code> flag (described below)
 </p>
 <p><b>Step 3a: Start the JMeter Client from a GUI client to check configuration</b></p>



Mime
View raw message