jmeter-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fschumac...@apache.org
Subject svn commit: r1843736 - /jmeter/trunk/xdocs/usermanual/remote-test.xml
Date Sat, 13 Oct 2018 10:24:20 GMT
Author: fschumacher
Date: Sat Oct 13 10:24:20 2018
New Revision: 1843736

URL: http://svn.apache.org/viewvc?rev=1843736&view=rev
Log:
spacepolice

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

Modified: jmeter/trunk/xdocs/usermanual/remote-test.xml
URL: http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/remote-test.xml?rev=1843736&r1=1843735&r2=1843736&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/remote-test.xml (original)
+++ jmeter/trunk/xdocs/usermanual/remote-test.xml Sat Oct 13 10:24:20 2018
@@ -6,9 +6,9 @@
    The ASF licenses this file to You under the Apache License, Version 2.0
    (the "License"); you may not use this file except in compliance with
    the License.  You may obtain a copy of the License at
- 
+
        http://www.apache.org/licenses/LICENSE-2.0
- 
+
    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
@@ -31,12 +31,12 @@
 
 <section name="&sect-num;. Remote Testing">
 
-<p>In the event that your JMeter client machine is unable, performance-wise, to simulate

+<p>In the event that your JMeter client machine is unable, performance-wise, to simulate
 enough users to stress your server or is limited at network level, an option exists to control
multiple, remote JMeter
-engines from a single JMeter client.  By running JMeter remotely, you can replicate 
+engines from a single JMeter client.  By running JMeter remotely, you can replicate
 a test across many low-end computers and thus simulate a larger load on the server.  One
 instance of the JMeter client can control any number of remote JMeter instances, and collect
-all the data from them.  This offers the following features: 
+all the data from them.  This offers the following features:
 
 <ul>
 <li>Saving of test samples to the local machine </li>
@@ -54,13 +54,13 @@ However, remote mode does use more resou
 If many server instances are used, the client JMeter can become overloaded, as can the client
network connection.
 This has been improved by switching to Stripped modes (see below) but you should always check
that your client is not overloaded.
 </p>
-<p>Note that while you can execute the JMeterEngine on your application 
-server, you need to be mindful of the fact that this will be adding processing 
-overhead on the application server and thus your testing results will be 
+<p>Note that while you can execute the JMeterEngine on your application
+server, you need to be mindful of the fact that this will be adding processing
+overhead on the application server and thus your testing results will be
 somewhat tainted.  The recommended approach is to have one or more machines on
 the same Ethernet segment as your application server that you configure to run
-the JMeter Engine.  This will minimize the impact of the network on the test 
-results without impacting the performance of the application server 
+the JMeter Engine.  This will minimize the impact of the network on the test
+results without impacting the performance of the application server
 itself.
 </p>
 
@@ -79,7 +79,7 @@ make sure that these are available in th
 If necessary you can define different values for properties by editing the <code>user.properties</code>
or <code>system.properties</code>
 files on each server. These properties will be picked up when the server is started and may
be
 used in the test plan to affect its behaviour (e.g. connecting to a different remote server).
-Alternatively use different content in any datafiles used by the test 
+Alternatively use different content in any datafiles used by the test
 (e.g. if each server must use unique ids, divide these between the data files)
 </p>
 
@@ -87,13 +87,13 @@ Alternatively use different content in a
 <p>To run JMeter in remote node, start the JMeter server component on all machines
you wish to run on by running
 the <code>JMETER_HOME/bin/jmeter-server</code> (unix) or <code>JMETER_HOME/bin/jmeter-server.bat</code>
(windows) script.</p>
 <p>Note that there can only be one JMeter server on each node unless different RMI
ports are used.</p>
-<p>Since JMeter 2.3.1, the JMeter server application starts the RMI registry itself;

+<p>Since JMeter 2.3.1, the JMeter server application starts the RMI registry itself;
 there is no need to start RMI registry separately.
 To revert to the previous behaviour, define the JMeter property <source>server.rmi.create=false</source>
on the server host systems.
 </p>
 <p>
 By default, RMI uses dynamic ports for the JMeter server engine. This can cause problems
for firewalls,
-so you can define the JMeter property <code>server.rmi.localport</code> 
+so you can define the JMeter property <code>server.rmi.localport</code>
 to control this port numbers.
 If this is non-zero, it will be used as the base for local port numbers for the server engine.
At the moment JMeter will open up to three ports beginning with the port defined in <code>server.rmi.localport</code>.
 </p>
@@ -108,9 +108,9 @@ instead to specify the remote host(s) to
 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>
-<p>Now you are ready to start the controlling JMeter client. For MS-Windows, start
the client with the script "<code>bin/jmeter.bat</code>".  For UNIX, 
-use the script "<code>bin/jmeter</code>".  You will notice that the Run menu
contains two new sub-menus: "Remote Start" and "Remote Stop" 
-(see figure 1). These menus contain the client that you set in the properties file.  Use
the remote start and stop instead of the 
+<p>Now you are ready to start the controlling JMeter client. For MS-Windows, start
the client with the script "<code>bin/jmeter.bat</code>".  For UNIX,
+use the script "<code>bin/jmeter</code>".  You will notice that the Run menu
contains two new sub-menus: "Remote Start" and "Remote Stop"
+(see figure 1). These menus contain the client that you set in the properties file.  Use
the remote start and stop instead of the
 normal JMeter start and stop menu items.</p>
 <figure image="remote/run-menu00.png" width="487" height="295">Figure 1 - Run Menu</figure>
 
@@ -187,8 +187,8 @@ directory.  Before running <code>rmiregi
     <li><code>JMETER_HOME/lib/jorphan.jar</code></li>
     <li><code>JMETER_HOME/lib/logkit-2.0.jar</code></li>
 </ul>
-The 
-rmiregistry application needs access to certain JMeter classes.  Run <code>rmiregistry</code>
with no parameters.  By default the 
+The
+rmiregistry application needs access to certain JMeter classes.  Run <code>rmiregistry</code>
with no parameters.  By default the
 application listens to port <code>1099</code>.</p>
 
 <p><b>Step 1b: Start the JMeter Server</b></p>
@@ -266,7 +266,7 @@ $ SERVER_PORT=1664 jmeter-server [other
 </source>
 [N.B. use upper case for the environment variable]
 <p>
-In both cases, the script starts rmiregistry on the specified port, 
+In both cases, the script starts rmiregistry on the specified port,
 and then starts JMeter in server mode, having defined the "<code>server_port</code>"
property.
 </p>
 <p>
@@ -287,7 +287,7 @@ There are some JMeter properties that ca
     <dl>
     <dt><code>Standard</code></dt><dd>send samples synchronously
as soon as they are generated</dd>
     <dt><code>Hold</code></dt><dd>hold samples in an array
until the end of a run. This may use a lot of memory on the server and is discouraged.</dd>
-    <dt><code>DiskStore</code></dt><dd>store samples in a disk
file (under <code>java.io.temp</code>) until the end of a run. 
+    <dt><code>DiskStore</code></dt><dd>store samples in a disk
file (under <code>java.io.temp</code>) until the end of a run.
     The serialised data file is deleted on JVM exit.</dd>
     <dt><code>StrippedDiskStore</code></dt><dd>remove responseData
from successful samples, and use DiskStore sender to send them.</dd>
     <dt><code>Batch</code></dt><dd>send saved samples when
either the count (<code>num_sample_threshold</code>) or time (<code>time_threshold</code>)
exceeds a threshold,
@@ -297,9 +297,9 @@ There are some JMeter properties that ca
         <dt><code>num_sample_threshold</code></dt><dd>number
of samples to accumulate, default <code>100</code></dd>
         <dt><code>time_threshold</code></dt><dd>time threshold,
default 60000 ms = 60 seconds</dd>
         </dl>
-    
+
      See also the Asynch mode, described below.</dd>
-    <dt><code>Statistical</code></dt><dd>send a summary sample
when either the count or time exceeds a threshold. 
+    <dt><code>Statistical</code></dt><dd>send a summary sample
when either the count or time exceeds a threshold.
     The samples are summarised by thread group name and sample label.
     The following fields are accumulated:
       <ul>
@@ -309,7 +309,7 @@ There are some JMeter properties that ca
       <li><code>sample count</code></li>
       <li><code>error count</code></li>
       </ul>
-    Other fields that vary between samples are lost. 
+    Other fields that vary between samples are lost.
     </dd>
     <dt><code>Stripped</code></dt><dd>remove responseData from
successful samples</dd>
     <dt><code>StrippedBatch</code></dt><dd>remove responseData
from successful samples, and use Batch sender to send them.</dd>
@@ -324,7 +324,7 @@ There are some JMeter properties that ca
     <dt><code>StrippedAsynch</code></dt><dd>remove responseData
from successful samples, and use Async sender to send them.</dd>
     <dt><code>Custom implementation</code></dt><dd>set the
mode parameter to your custom sample sender class name.
     This must implement the interface <code>SampleSender</code> and have a constructor
which takes a single
-    parameter of type <code>RemoteSampleListener</code>. 
+    parameter of type <code>RemoteSampleListener</code>.
     </dd>
     </dl>
     </dd>
@@ -343,14 +343,14 @@ This is not really a problem as there is
 
 <subsection name="&sect-num;.6 Dealing with nodes that failed starting" anchor="retries">
   <p>
-    For large-scale tests there is a chance that some part of remote servers will be unavailable
or down. 
+    For large-scale tests there is a chance that some part of remote servers will be unavailable
or down.
     For example, when you use automation script to allocate many cloud machines and use them
as generators,
     some of requested machines might fail booting because of cloud's issues.
     Since JMeter 2.13 there are new properties to control this behaviour.
   </p>
   <p>
-    First what you might want is to retry initialization attempts in hope that failed nodes
just slightly delayed their boot. 
-    To enable retries, you should set <code>client.tries</code> property to total
number of connection attempts. 
+    First what you might want is to retry initialization attempts in hope that failed nodes
just slightly delayed their boot.
+    To enable retries, you should set <code>client.tries</code> property to total
number of connection attempts.
     By default it does only one attempt. To control retry delay, set the <code>client.retries_delay</code>
property
     to number of milliseconds to sleep between attempts.
   </p>



Mime
View raw message