Author: pmouawad
Date: Thu Feb 14 17:56:13 2019
New Revision: 1853594
URL: http://svn.apache.org/viewvc?rev=1853594&view=rev
Log:
Bug 63177 - Rename NON GUI mode into CLI Mode in documentation
Update docs
Bugzilla Id: 63177
Modified:
jmeter/trunk/xdocs/changes.xml
jmeter/trunk/xdocs/index.xml
jmeter/trunk/xdocs/usermanual/best-practices.xml
jmeter/trunk/xdocs/usermanual/boss.xml
jmeter/trunk/xdocs/usermanual/build-test-plan.xml
jmeter/trunk/xdocs/usermanual/component_reference.xml
jmeter/trunk/xdocs/usermanual/get-started.xml
jmeter/trunk/xdocs/usermanual/index.xml
jmeter/trunk/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
jmeter/trunk/xdocs/usermanual/jmeter_proxy_step_by_step.xml
jmeter/trunk/xdocs/usermanual/listeners.xml
jmeter/trunk/xdocs/usermanual/properties_reference.xml
jmeter/trunk/xdocs/usermanual/remote-test.xml
Modified: jmeter/trunk/xdocs/changes.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/changes.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/changes.xml [utf-8] (original)
+++ jmeter/trunk/xdocs/changes.xml [utf-8] Thu Feb 14 17:56:13 2019
@@ -219,6 +219,7 @@ containing a fix to this issue, we decid
<li><bug>62821</bug><pr>405</pr>Use SHA-512 checksums instead of MD5 to
verify jar downloads</li>
<li><bug>63053</bug>Remove referrals to never implemented internals from
user documentation. Reported by U. Poblotzki (u.poblotzki at thalia.de)</li>
<li><bug>63082</bug><pr>437</pr>Use utf-8 for properties files in
source</li>
+ <li><bug>63177</bug>Rename NON GUI mode into CLI Mode in documentation</li>
</ul>
<!-- =================== Bug fixes =================== -->
Modified: jmeter/trunk/xdocs/index.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/index.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/index.xml (original)
+++ jmeter/trunk/xdocs/index.xml Thu Feb 14 17:56:13 2019
@@ -57,7 +57,7 @@
</ul>
</li>
<li>Full featured Test IDE that allows fast Test Plan <b>recording (from
Browsers or native applications), building and debugging</b>.</li>
- <li><b><a href="usermanual/get-started.html#non_gui">Command-line mode
(Non GUI / headless mode)</a></b> to load test from any Java compatible OS
(Linux, Windows, Mac OSX, …)</li>
+ <li><b><a href="usermanual/get-started.html#non_gui">CLI mode
(Command-line mode (previously called Non GUI) / headless mode)</a></b> to load
test from any Java compatible OS (Linux, Windows, Mac OSX, …)</li>
<li>A complete and <b><a href="usermanual/generating-dashboard.html"
>ready to present dynamic HTML report</a></b></li>
<li>Easy correlation through ability to extract data from most popular
response formats, <b><a
href="usermanual/component_reference.html#CSS/JQuery_Extractor" >HTML</a>, <a
href="usermanual/component_reference.html#JSON_Extractor" >JSON </a>,
<a href="usermanual/component_reference.html#XPath_Extractor" >XML</a>
or <a href="usermanual/component_reference.html#Regular_Expression_Extractor"
>any textual format</a></b></li>
Modified: jmeter/trunk/xdocs/usermanual/best-practices.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/best-practices.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/best-practices.xml (original)
+++ jmeter/trunk/xdocs/usermanual/best-practices.xml Thu Feb 14 17:56:13 2019
@@ -45,7 +45,7 @@ You should absolutely avoid using versio
run with JMeter. The number will also depend on how fast your server is (a
faster server
makes JMeter work harder since it returns a response quicker). As with any
Load Testing tool, if you don't correctly size
the number of threads, you will face the "Coordinated Omission" problem which
can give you wrong or inaccurate results.
- If you need large-scale load testing, consider running multiple non-GUI
JMeter instances on multiple machines
+ If you need large-scale load testing, consider running multiple CLI JMeter
instances on multiple machines
using distributed mode (or not). When using distributed mode the result file
is combined on the Controller node, if
using multiple autonomous instances, the sample result files can be combined
for subsequent analysis.
For testing how JMeter performs on a given platform, the JavaTest sampler can
be used.
@@ -150,7 +150,7 @@ samplers
Some suggestions on reducing resource usage.
</p>
<ul>
-<li>Use non-GUI mode: <code>jmeter -n -t test.jmx -l test.jtl</code></li>
+<li>Use CLI 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,
@@ -230,7 +230,7 @@ bsh % … disconnected from server.
</source>
</p>
<p>
-As a practical example, assume you have a long-running JMeter test running in
non-GUI mode,
+As a practical example, assume you have a long-running JMeter test running in
CLI mode,
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. <code>${__P(throughput)}</code>.
@@ -354,7 +354,7 @@ For example, one could define the variab
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.
+This quickly becomes tedious if you want to run lots of tests in CLI 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 "<code>loops</code>", defaulting to
<code>10</code> if the property is not found.
Modified: jmeter/trunk/xdocs/usermanual/boss.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/boss.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/boss.xml (original)
+++ jmeter/trunk/xdocs/usermanual/boss.xml Thu Feb 14 17:56:13 2019
@@ -104,7 +104,7 @@ for the testing account).
<p>
Also note that some Linux/Unix editions are intended for server use.
These generally have minimal or no GUI support.
-Such OSes should be OK for running JMeter in non-GUI mode, but JMeter GUI mode
probably won't work
+Such OSes should be OK for running JMeter in CLI mode, but JMeter GUI mode
probably won't work
unless you install a minimal GUI environment.
</p>
<p>As you progress to larger-scale benchmarks/load-tests, this platform
@@ -116,10 +116,10 @@ configuration in your published benchmar
JMeter can easily be installed on Cloud instances as it runs on nearly any
architecture available in the Cloud.
JMeter is also supported within Commercial Cloud PAAS if you don't want to
manage it yourself.
</p>
-<p>Don't forget JMeter batch (NON-GUI) mode. This mode should be used during
load testing for many reasons:
+<p>Don't forget JMeter batch (CLI) mode. This mode should be used during load
testing for many reasons:
<ul>
<li>If you have a powerful server that supports Java but perhaps does not have
a fast graphics implementation, or where you need to login remotely.</li>
-<li>Batch (non-GUI) mode can reduce the network traffic compared with using a
remote display or client-server mode.</li>
+<li>Batch (CLI) mode can reduce the network traffic compared with using a
remote display or client-server mode.</li>
<li>Java AWT Thread used for GUI mode can alter injection behaviour by
blocking sometimes</li>
</ul>
The batch log file can then be loaded into JMeter on a workstation for
analysis, or you can
Modified: jmeter/trunk/xdocs/usermanual/build-test-plan.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/build-test-plan.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/build-test-plan.xml (original)
+++ jmeter/trunk/xdocs/usermanual/build-test-plan.xml Thu Feb 14 17:56:13 2019
@@ -89,7 +89,7 @@ then JMeter is running your test plan (o
The numbers to the left of the green box are the number of active threads /
total number of threads.
These only apply to a locally run test; they do not include any threads
started on remote systems when using client-server mode.
</p>
-<note>Using GUI mode as described here should only be used when debugging your
Test Plan. To run the real load test, use NON-GUI mode.</note>
+<note>Using GUI mode as described here should only be used when debugging your
Test Plan. To run the real load test, use CLI mode.</note>
</subsection>
<subsection name="§-num;.6 Stopping a Test" anchor="stop">
@@ -111,8 +111,8 @@ The modal shutdown dialog box will remai
If Shutdown is taking too long. Close the Shutdown dialog box and select
<code>Run</code>/<code>Stop</code>, or just press
<keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
</p>
<p>
-When running JMeter in non-GUI mode, there is no Menu, and JMeter does not
react to keystrokes such as
<keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
-So JMeter non-GUI mode will listen for commands on a specific port (default
<code>4445</code>, see the JMeter property
<code>jmeterengine.nongui.port</code>).
+When running JMeter in CLI mode, there is no Menu, and JMeter does not react
to keystrokes such as
<keycombo><keysym>Control</keysym><keysym>.</keysym></keycombo>.
+So JMeter CLI mode will listen for commands on a specific port (default
<code>4445</code>, see the JMeter property
<code>jmeterengine.nongui.port</code>).
JMeter supports automatic choice of an alternate port if the default port is
being used
(for example by another JMeter instance). In this case, JMeter will try the
next higher port, continuing until
it reaches the JMeter property <code>jmeterengine.nongui.maxport</code>) which
defaults to <code>4455</code>.
Modified: jmeter/trunk/xdocs/usermanual/component_reference.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/component_reference.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/component_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/component_reference.xml Thu Feb 14 17:56:13
2019
@@ -1758,7 +1758,7 @@ The "<code>Stop</code>" action stops the
The "<code>Stop Now</code>" action stops the test without waiting for samples
to complete; it will interrupt any active samples.
If some threads fail to stop within the 5 second time-limit, a message will be
displayed in GUI mode.
You can try using the <code>Stop</code> command to see if this will stop the
threads, but if not, you should exit JMeter.
-In non-GUI mode, JMeter will exit if some threads fail to stop within the 5
second time limit.
+In CLI mode, JMeter will exit if some threads fail to stop within the 5 second
time limit.
<note>The time to wait can be changed using the JMeter property
<code>jmeterengine.threadstop.wait</code>. The time is given in
milliseconds.</note>
</p>
</description>
@@ -2570,9 +2570,9 @@ files, typically with a "<code>.jtl</cod
Storing as CSV is the most efficient option, but is less detailed than XML
(the other available option).
</p>
<p>
-<b>Listeners do <i>not</i> process sample data in non-GUI mode, but the raw
data will be saved if an output
+<b>Listeners do <i>not</i> process sample data in CLI mode, but the raw data
will be saved if an output
file has been configured.</b>
-In order to analyse the data generated by a non-GUI test run, you need to load
the file into the appropriate
+In order to analyse the data generated by a CLI run, you need to load the file
into the appropriate
Listener.
</p>
<note>
@@ -2974,7 +2974,7 @@ If this is selected, then the sub-sample
<description>This listener can record results to a file
but not to the UI. It is meant to provide an efficient means of
recording data by eliminating GUI overhead.
-When running in non-GUI mode, the <code>-l</code> flag can be used to create a
data file.
+When running in CLI mode, the <code>-l</code> flag can be used to create a
data file.
The fields to save are defined by JMeter properties.
See the <code>jmeter.properties</code> file for details.
</description>
@@ -3266,7 +3266,7 @@ time boundary, so that multiple test run
See <code>jmeter.properties</code> file for the summariser configuration items:
<source>
# Define the following property to automatically start a summariser with that
name
-# (applies to non-GUI mode only)
+# (applies to CLI mode only)
#summariser.name=summary
#
# interval between summaries (in seconds) default 3 minutes
@@ -3278,7 +3278,7 @@ See <code>jmeter.properties</code> file
# Write messages to System.out
#summariser.out=true
</source>
-This element is mainly intended for batch (non-GUI) runs.
+This element is mainly intended for batch (CLI) runs.
The output looks like the following:
<source>
label + 16 in 0:00:12 = 1.3/s Avg: 1608 Min: 1163 Max: 2009 Err:
0 (0.00%) Active: 5 Started: 5 Finished: 0
@@ -3324,7 +3324,7 @@ Different summary groupings can be imple
by using suitable labels and adding the summarisers to appropriate parts of
the test plan.
</p>
<note>
-In Non-GUI mode by default a Generate Summary Results listener named
"<code>summariser</code>" is configured, if you have already added one to your
Test Plan, ensure you name it differently
+In CLI mode by default a Generate Summary Results listener named
"<code>summariser</code>" is configured, if you have already added one to your
Test Plan, ensure you name it differently
otherwise results will be accumulated under this label (summary) leading to
wrong results (sum of total samples + samples located under the Parent of
Generate Summary Results listener).<br/>
This is not a bug but a design choice allowing to summarize across thread
groups.
</note>
Modified: jmeter/trunk/xdocs/usermanual/get-started.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/get-started.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/get-started.xml (original)
+++ jmeter/trunk/xdocs/usermanual/get-started.xml Thu Feb 14 17:56:13 2019
@@ -60,9 +60,9 @@ The first step is to configure the injec
<li><b>Increase the Java Heap size</b>. By default JMeter runs with a heap
of 1 GB, this might not be enough for your test and depends on your test plan
and number of threads you want to run</li>
</ul>
-Once everything is ready, you will use Command-line mode (called <a
href="#non_gui">Non-GUI mode</a>) to run it for the Load Test.
+Once everything is ready, you will use CLI mode (Command-line mode previously
called <a href="#non_gui">Non-GUI mode</a>) to run it for the Load Test.
<note>Don't run load test using GUI mode !</note><br/>
-Using Non-GUI mode, you can generate a CSV (or XML) file containing results
and have JMeter <a href="generating-dashboard.html">generate an HTML report</a>
at end of Load Test.
+Using CLI mode, you can generate a CSV (or XML) file containing results and
have JMeter <a href="generating-dashboard.html">generate an HTML report</a> at
end of Load Test.
JMeter will by default provide a summary of load test while it's running. <br/>
You can also have <a href="realtime-results.html" >real-time results</a>
during your test using <a
href="component_reference.html#Backend_Listener">Backend Listener</a>.
</p>
@@ -235,7 +235,7 @@ You can rename the parent directory (i.e
<p>To run JMeter, run the <code>jmeter.bat</code> (for Windows) or
<code>jmeter</code> (for Unix) file.
These files are found in the <code>bin</code> directory.
After a short time, the JMeter GUI should appear.
-<note>GUI mode should only be used for creating the test script, NON GUI mode
must be used for load testing</note>
+<note>GUI mode should only be used for creating the test script, CLI mode (NON
GUI) must be used for load testing</note>
</p>
<p>
@@ -245,13 +245,13 @@ Windows script files (the .CMD files req
<dl>
<dt><code>jmeter.bat</code></dt><dd>run JMeter (in GUI mode by default)</dd>
<dt><code>jmeterw.cmd</code></dt><dd>run JMeter without the windows shell
console (in GUI mode by default)</dd>
-<dt><code>jmeter-n.cmd</code></dt><dd>drop a JMX file on this to run a non-GUI
test</dd>
-<dt><code>jmeter-n-r.cmd</code></dt><dd>drop a JMX file on this to run a
non-GUI test remotely</dd>
+<dt><code>jmeter-n.cmd</code></dt><dd>drop a JMX file on this to run a CLI
mode test</dd>
+<dt><code>jmeter-n-r.cmd</code></dt><dd>drop a JMX file on this to run a CLI
mode test remotely</dd>
<dt><code>jmeter-t.cmd</code></dt><dd>drop a JMX file on this to load it in
GUI mode</dd>
<dt><code>jmeter-server.bat</code></dt><dd>start JMeter in server mode</dd>
-<dt><code>mirror-server.cmd</code></dt><dd>runs the JMeter Mirror Server in
non-GUI mode</dd>
-<dt><code>shutdown.cmd</code></dt><dd>Run the Shutdown client to stop a
non-GUI instance gracefully</dd>
-<dt><code>stoptest.cmd</code></dt><dd>Run the Shutdown client to stop a
non-GUI instance abruptly</dd>
+<dt><code>mirror-server.cmd</code></dt><dd>runs the JMeter Mirror Server in
CLI mode</dd>
+<dt><code>shutdown.cmd</code></dt><dd>Run the Shutdown client to stop a CLI
mode instance gracefully</dd>
+<dt><code>stoptest.cmd</code></dt><dd>Run the Shutdown client to stop a CLI
mode instance abruptly</dd>
</dl>
<note>The special name <code>LAST</code> can be used with
<code>jmeter-n.cmd</code>, <code>jmeter-t.cmd</code> and
<code>jmeter-n-r.cmd</code>
and means the last test plan that was run interactively.</note>
@@ -295,9 +295,9 @@ Un*x script files; should work on most L
<dt><code>jmeter</code></dt><dd>run JMeter (in GUI mode by default). Defines
some JVM settings which may not work for all JVMs.</dd>
<dt><code>jmeter-server</code></dt><dd>start JMeter in server mode (calls
jmeter script with appropriate parameters)</dd>
<dt><code>jmeter.sh</code></dt><dd>very basic JMeter script (You may need to
adapt JVM options like memory settings).</dd>
-<dt><code>mirror-server.sh</code></dt><dd>runs the JMeter Mirror Server in
non-GUI mode</dd>
-<dt><code>shutdown.sh</code></dt><dd>Run the Shutdown client to stop a non-GUI
instance gracefully</dd>
-<dt><code>stoptest.sh</code></dt><dd>Run the Shutdown client to stop a non-GUI
instance abruptly</dd>
+<dt><code>mirror-server.sh</code></dt><dd>runs the JMeter Mirror Server in CLI
mode</dd>
+<dt><code>shutdown.sh</code></dt><dd>Run the Shutdown client to stop a CLI
mode instance gracefully</dd>
+<dt><code>stoptest.sh</code></dt><dd>Run the Shutdown client to stop a CLI
mode instance abruptly</dd>
</dl>
<p>
It may be necessary to set a few environment variables to configure the JVM
used by JMeter. Those variables can be either set directly in the shell
starting the <code>jmeter</code> script. For example setting the variable
<code>JVM_ARGS</code> will override most pre-defined settings, for example
@@ -443,11 +443,11 @@ This is only used for recording HTTP or
This is not to be confused with the proxy settings described above, which are
used when JMeter makes HTTP or HTTPS requests itself.</note>
</subsection>
-<subsection name="§-num;.4.4 Non-GUI Mode (Command Line mode)"
anchor="non_gui">
+<subsection name="§-num;.4.4 CLI Mode (Command Line mode was called NON
GUI mode)" anchor="non_gui">
<p>For load testing, you must run JMeter in this mode (Without the GUI) to get
the optimal results from it. To do so, use
the following command options:</p>
<dl>
-<dt><code>-n</code></dt><dd>This specifies JMeter is to run in non-gui
mode</dd>
+<dt><code>-n</code></dt><dd>This specifies JMeter is to run in cli mode</dd>
<dt><code>-t</code></dt><dd>[name of JMX file that contains the Test
Plan].</dd>
<dt><code>-l</code></dt><dd>[name of JTL file to log sample results to].</dd>
<dt><code>-j</code></dt><dd>[name of JMeter run log file].</dd>
@@ -473,7 +473,7 @@ Normally this is not necessary.
<subsection name="§-num;.4.5 Server Mode" anchor="server">
<p>For <a href="remote-test.html">distributed testing</a>, run JMeter in
server mode on the remote node(s), and then control the server(s) from the GUI.
-You can also use non-GUI mode to run remote tests.
+You can also use CLI mode to run remote tests.
To start the server(s), run <code>jmeter-server[.bat]</code> on each server
host.</p>
<p>The script also lets you specify the optional firewall/proxy server
information:</p>
<dl>
@@ -484,7 +484,7 @@ To start the server(s), run <code>jmeter
<source>jmeter-server -H my.proxy.server -P 8000</source>
<p>If you want the server to exit after a single test has been run, then
define the JMeter property <code>server.exitaftertest=true</code>.
</p>
-<p>To run the test from the client in non-GUI mode, use the following
command:</p>
+<p>To run the test from the client in CLI mode, use the following command:</p>
<source>
jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X]
</source>
@@ -789,7 +789,7 @@ These are shown below.</p>
-d, --homedir <argument>
the jmeter home directory to use
-X, --remoteexit
- Exit the remote servers at end of test (non-GUI)
+ Exit the remote servers at end of test (CLI mode)
-g, --reportonly <argument>
generate report dashboard only, from a test results file
-e, --reportatendofloadtests
@@ -808,9 +808,9 @@ that was run in interactive mode.
</p>
</subsection>
-<subsection name="§-num;.4.9 non-GUI shutdown" anchor="shutdown">
+<subsection name="§-num;.4.9 CLI mode shutdown" anchor="shutdown">
<p>
-Prior to version 2.5.1, JMeter invoked <code>System.exit()</code> when a
non-GUI test completed.
+Prior to version 2.5.1, JMeter invoked <code>System.exit()</code> when a CLI
mode test completed.
This caused problems for applications that invoke JMeter directly, so JMeter
no longer invokes <code>System.exit()</code>
for a normal test completion. [Some fatal errors may still invoke
<code>System.exit()</code>]
JMeter will exit all the non-daemon threads it starts, but it is possible that
some non-daemon threads
Modified: jmeter/trunk/xdocs/usermanual/index.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/index.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/index.xml (original)
+++ jmeter/trunk/xdocs/usermanual/index.xml Thu Feb 14 17:56:13 2019
@@ -89,12 +89,12 @@
<li><a href="get-started.html#classpath">1.4.1 JMeter's
Classpath</a></li>
<li><a href="get-started.html#template">1.4.2 Create Test Plan from
Template</a></li>
<li><a href="get-started.html#proxy_server">1.4.3 Using JMeter behind
a proxy</a></li>
- <li><a href="get-started.html#non_gui">1.4.4 Non-GUI Mode</a></li>
+ <li><a href="get-started.html#non_gui">1.4.4 CLI mode</a></li>
<li><a href="get-started.html#server">1.4.5 Server Mode</a></li>
<li><a href="get-started.html#override">1.4.6 Overriding Properties
Via The Command Line</a></li>
<li><a href="get-started.html#logging">1.4.7 Logging and Error
Messages</a></li>
<li><a href="get-started.html#options">1.4.8 Full list of command-line
options</a></li>
- <li><a href="get-started.html#shutdown">1.4.9 non-GUI shutdown</a></li>
+ <li><a href="get-started.html#shutdown">1.4.9 CLI mode
shutdown</a></li>
</ul>
</li>
<li><a href="get-started.html#configuring_jmeter">1.5 Configuring
JMeter</a></li>
Modified:
jmeter/trunk/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
(original)
+++ jmeter/trunk/xdocs/usermanual/jmeter_distributed_testing_step_by_step.xml
Thu Feb 14 17:56:13 2019
@@ -51,7 +51,7 @@ Once you've made sure the systems are re
have JMeter installed on all the systems. The way JMeter works is one master
controller initiates the test on multiple slave systems.
</p>
-<note>In this tutorial we use GUI Mode just for demonstration. In real life
you should use NON GUI mode to start your load test</note>
+<note>In this tutorial we use GUI Mode just for demonstration. In real life
you should use CLI mode (NON GUI) to start your load test</note>
<figure width="610" height="462" image="distributed-jmeter.svg">One master
controls multiple slaves</figure>
Modified: jmeter/trunk/xdocs/usermanual/jmeter_proxy_step_by_step.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/jmeter_proxy_step_by_step.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/jmeter_proxy_step_by_step.xml (original)
+++ jmeter/trunk/xdocs/usermanual/jmeter_proxy_step_by_step.xml Thu Feb 14
17:56:13 2019
@@ -205,7 +205,7 @@ ready to run the test, there are two way
<p>
-Solution 1, with the gui, but just during debug phase, use Non GUI for your
load test.
+Solution 1, with the gui, but just during debug phase, use CLI mode (Non GUI)
for your load test.
</p>
<p>
<menuchoice>
Modified: jmeter/trunk/xdocs/usermanual/listeners.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/listeners.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/listeners.xml (original)
+++ jmeter/trunk/xdocs/usermanual/listeners.xml Thu Feb 14 17:56:13 2019
@@ -69,7 +69,7 @@ The same filename can be used by multipl
<p>
The default items to be saved can be defined in the
<code>jmeter.properties</code> (or <code>user.properties</code>) file.
The properties are used as the initial settings for the Listener Config
pop-up, and are also
-used for the log file specified by the <code>-l</code> command-line flag
(commonly used for non-GUI test runs).
+used for the log file specified by the <code>-l</code> command-line flag
(commonly used for CLI mode test runs).
</p>
<p>To change the default format, find the following line in
<code>jmeter.properties</code>:</p>
<source>jmeter.save.saveservice.output_format=</source>
@@ -237,9 +237,9 @@ Note that cookies, method and the query
</p>
</section>
-<section name="§-num;.2 non-GUI (batch) test runs" anchor="batch">
+<section name="§-num;.2 CLI mode (batch) test runs" anchor="batch">
<p>
-When running in non-GUI mode, the <code>-l</code> flag can be used to create a
top-level listener for the test run.
+When running in CLI mode, the <code>-l</code> flag can be used to create a
top-level listener for the test run.
This is in addition to any Listeners defined in the test plan.
The configuration of this listener is controlled by entries in the file
<code>jmeter.properties</code>
as described in the previous section.
Modified: jmeter/trunk/xdocs/usermanual/properties_reference.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/properties_reference.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/properties_reference.xml (original)
+++ jmeter/trunk/xdocs/usermanual/properties_reference.xml Thu Feb 14 17:56:13
2019
@@ -1066,12 +1066,12 @@ JMETER-SERVER</source>
Defaults to: <code>2</code></property>
</properties>
</section>
-<section name="§-num;.26 Summariser - Generate Summary Results -
configuration (mainly applies to non-GUI mode)" anchor="summariser">
+<section name="§-num;.26 Summariser - Generate Summary Results -
configuration (mainly applies to CLI mode)" anchor="summariser">
<properties>
<property name="summariser.name">
- Comment the following property to disable the default non-GUI
summariser.<br/>
+ Comment the following property to disable the default CLI mode
summariser.<br/>
[or change the value to rename it]<br/>
- <note>Applies to non-GUI mode only</note>
+ <note>Applies to CLI mode only</note>
Defaults to: <code>summary</code>
</property>
<property name="summariser.interval">
@@ -1409,14 +1409,13 @@ JMETER-SERVER</source>
Defaults to: <code>false</code>
</property>
<property name="jmeterengine.stopfail.system.exit">
- Whether to call <code>System.exit(1)</code> on failure to stop threads in
- non-GUI mode.<br/>
+ Whether to call <code>System.exit(1)</code> on failure to stop threads in
CLI mode.<br/>
This only takes effect if the test was explicitly requested to stop.<br/>
If this is disabled, it may be necessary to kill the JVM externally.<br/>
Defaults to: <code>true</code>
</property>
<property name="jmeterengine.force.system.exit">
- Whether to force call <code>System.exit(0)</code> at end of test in
non-GUI mode,
+ Whether to force call <code>System.exit(0)</code> at end of test in CLI
mode,
even if there were no failures and the test was not explicitly asked to
stop.<br/>
Without this, the JVM may never exit if there are other threads spawned by
the test which never exit.<br/>
@@ -1429,7 +1428,7 @@ JMETER-SERVER</source>
Defaults to: <code>2000</code>
</property>
<property name="jmeterengine.nongui.port">
- If running non-GUI, then JMeter listens on the following port for a
shutdown message.<br/>
+ If running CLI mode, then JMeter listens on the following port for a
shutdown message.<br/>
To disable, set the port to <code>1000</code> or less.<br/>
Defaults to: <code>4445</code>
</property>
@@ -1543,7 +1542,7 @@ JMETER-SERVER</source>
</property>
<property name="classfinder.functions.contain">
The classpath finder currently needs to load every single JMeter class to
find the classes it needs.<br/>
- For non-GUI mode, it's only necessary to scan for Function classes, but
all classes are still loaded.<br/>
+ For CLI mode, it's only necessary to scan for Function classes, but all
classes are still loaded.<br/>
All current Function classes include "<code>.function.</code>" in their
name, and none include
"<code>.gui.</code>" in the name, so the number of unwanted classes loaded
can be reduced by
checking for these. However, if a valid function class name does not match
these restrictions,
Modified: jmeter/trunk/xdocs/usermanual/remote-test.xml
URL:
http://svn.apache.org/viewvc/jmeter/trunk/xdocs/usermanual/remote-test.xml?rev=1853594&r1=1853593&r2=1853594&view=diff
==============================================================================
--- jmeter/trunk/xdocs/usermanual/remote-test.xml (original)
+++ jmeter/trunk/xdocs/usermanual/remote-test.xml Thu Feb 14 17:56:13 2019
@@ -50,7 +50,7 @@ JMeter does not distribute the load betw
So if you set 1000 Threads and have 6 JMeter server, you end up injecting 6000
Threads.
</note>
<p>
-However, remote mode does use more resources than running the same number of
non-GUI tests independently.
+However, remote mode does use more resources than running the same number of
CLI mode tests independently.
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>
@@ -114,9 +114,9 @@ use the script "<code>bin/jmeter</code>"
normal JMeter start and stop menu items.</p>
<figure image="remote/run-menu00.png" width="487" height="295">Figure 1 - Run
Menu</figure>
-<p><b>Step 3b: Start the JMeter from a non-GUI Client</b></p>
+<p><b>Step 3b: Start the JMeter from a CLI mode Client</b></p>
<p>
-GUI mode should only be used for debugging, as a better alternative, you
should start the test on remote server(s) from a non-GUI (command-line) client.
+GUI mode should only be used for debugging, as a better alternative, you
should start the test on remote server(s) from a CLI mode (command-line) client.
The command to do this is:</p>
<source>
jmeter -n -t script.jmx -r
