xdocs/usermanual/build-monitor-test-plan.xml - jmeter - Git at Google

 <?xml version="1.0"?>
 <!--
    Licensed to the Apache Software Foundation (ASF) under one or more
    contributor license agreements.  See the NOTICE file distributed with
    this work for additional information regarding copyright ownership.
    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.
    See the License for the specific language governing permissions and
    limitations under the License.
 -->
 <!DOCTYPE document
 [
 <!ENTITY sect-num '12'>
 ]>
 <document prev="build-jms-topic-test-plan.html" next="listeners.html" id="$Id$">

 <properties>
   <title>User's Manual: Building a Monitor Test Plan (REMOVED since JMeter 3.2)</title>
 </properties>

 <body>

 <section name="&sect-num;. Building a Monitor Test Plan (REMOVED since JMeter 3.2)" anchor="building">
 <note>Note this feature is deprecated since JMeter 3.1</note>
 <p>In this section, you will learn how to create a
 <a href="build-test-plan.html">Test Plan</a> to monitor webservers. Monitors
 are useful for a stress testing and system management. Used with stress
 testing, the monitor provides additional information about server performance.
 It also makes it easier to see the relationship between server performance
 and response time on the client side. As a system administration tool, the
 monitor provides an easy way to monitor multiple servers from one console.
 The monitor was designed to work with the status servlet in Tomcat 5. In
 theory, any servlet container that supports JMX (Java Management Extension)
 can port the status servlet to provide the same information.</p>
 <p>For those who want to use the monitor with other servlet or EJB containers,
 Tomcat's status servlet should work with other containers for the memory
 statistics without any modifications. To get thread information, you will
 need to change the MBeanServer lookup to retrieve the correct MBeans.</p>

 </section>

 <section name="&sect-num;.1 Adding A Server" anchor="adding_server">
 <p>The first step is to add a <a href="test_plan.html#thread_group">Thread Group</a>
 element.  The Thread Group tells JMeter the number of threads you want. Always use
 <code>1</code>, since we are using JMeter as a monitor. This is very important for those not
 familiar with server monitors. As a general rule, using multiple threads for a
 single server is bad and can create significant stress.
 </p>

 <p>Go ahead and add the ThreadGroup element by first selecting the Test Plan,
 clicking your right mouse button to get the <menuchoice><guimenuitem>Add</guimenuitem></menuchoice> menu, and then select
 <menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>ThreadGroup</guimenuitem>
 </menuchoice>.</p>

 <p>You should now see the Thread Group element under Test Plan.  If you do not
 see the element, "expand" the Test Plan tree by clicking on the Test Plan element.</p>

 <figure image="webtest/threadgroup.png">
 Figure &sect-num;.1. Thread Group with Default Values</figure>

 <p>Change the loop count to forever (or some large number) so that enough samples are generated.</p>

 </section>

 <section name="&sect-num;.2 HTTP Auth Manager" anchor="adding_auth">
 <p>Add the <complink name="HTTP Authorization Manager"/> to the Thread Group element
 (<menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>Config element</guimenuitem>
   <guimenuitem>HTTP Authorization Manager</guimenuitem>
 </menuchoice>). Enter the username
 and password for your webserver.
 <note>Important note: the monitor only works with
 Tomcat5 build 5.0.19 and newer. For instructions on how to setup Tomcat, please
 refer to tomcat 5 documentation.
 </note>
 </p>
 <ol>
 <li> leave the base URL blank</li>
 <li> enter the username</li>
 <li> enter the password</li>
 </ol>
 </section>

 <section name="&sect-num;.3 Adding HTTP Request" anchor="adding_request">

 <p>Add the <complink name="HTTP Request"/> to the Thread Group element
 (<menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>Sampler</guimenuitem>
   <guimenuitem>HTTP Request</guimenuitem>
 </menuchoice>). Then, select the HTTP Request element
 in the tree and edit the following properties):
 <ol>
 <li>Change the Name field to "<code>Server Status</code>".</li>
 <li>Enter the IP address or Hostname</li>
 <li>Enter the port number</li>
 <li>Set the Path field to "<code>/manager/status</code>" if you're using Tomcat.</li>
 <li>Add a request parameter named "<code>XML</code>" in uppercase. Give it a value of
 "<code>true</code>" in lowercase.</li>
 <li>Check "<code>Use as Monitor</code>" at the bottom of the sampler</li>
 </ol>
 </p>

 </section>

 <section name="&sect-num;.4 Adding Constant Timer" anchor="adding_timer">

 <p>Add a timer to this thread group
 (<menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>Timer</guimenuitem>
   <guimenuitem>Constant Timer</guimenuitem>
 </menuchoice>).
 Enter <code>5000</code> milliseconds in the "<code>Thread Delay</code>" box. In general, using intervals shorter
 than 5 seconds will add stress to your server. Find out what is an acceptable interval
 before you deploy the monitor in your production environment.</p>

 </section>

 <section name="&sect-num;.5 Adding a Listener to Store the Results" anchor="adding_listener">
 <p>If you want to save the raw results from the server, add a simple data
  <a href="component_reference.html#listeners">Listener</a>. If you want to save the
  calculated statistics, enter a filename in the listener. If you want to save both
  the raw data and statistics, make sure you use different filenames.</p>

 <p>Select the thread group element and add a <complink name="Simple Data Writer"/> listener
 (<menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>Listener</guimenuitem>
   <guimenuitem>Simple Data Writer</guimenuitem>
 </menuchoice>).  Next, you need to specify a directory
 and filename of the output file.  You can either type it into the filename field, or
 select the Browse button and browse to a directory and then enter a filename.</p>

 </section>

 <section name="&sect-num;.6 Adding Monitor Results" anchor="add_monitor_listener">

 <p>Add the <a href="component_reference.html#listeners">Listener</a> by selecting the
 test plan element
 (<menuchoice>
   <guimenuitem>Add</guimenuitem>
   <guimenuitem>Listener</guimenuitem>
   <guimenuitem>Monitor Results</guimenuitem>
 </menuchoice>).
 </p><p>
 By default, the Listener will select the results from the first connector in the sample response.
 The Connector prefix field can be used to select a different connector.
 If specified, the Listener will choose the first connector which matches the prefix.
 If no match is found, then the first connector is selected.
 </p>
 <p>There are two tabs in
 the monitor results listener. The first is the "<code>Health</code>", which displays the status of
 the last sample the monitor received. The second tab is "<code>Performance</code>", which shows a
 historical view of the server's performance.
 </p>

 <figure image="monitor_health.png"/>
 <p>A quick note about how health is calculated. Typically, a server will crash if
 it runs out of memory, or reached the maximum number of threads. In the case of
 Tomcat 5, once the threads are maxed out, requests are placed in a queue until a
 thread is available. The relative importance of threads vary between containers, so
 the current implementation uses 50/50 to be conservative. A container that is more
 efficient with thread management might not see any performance degradation, but
 the used memory definitely will show an impact.</p>
 <figure image="monitor_screencap.png"/>
 <p>The performance graph shows four different lines. The free memory line shows how
 much free memory is left in the current allocated block. Tomcat 5 returns the maximum
 memory, but it is not graphed. In a well tuned environment, the server should never
 reach the maximum memory.</p>
 <p>Note the graph has captions on both sides of the graph. On the left is percent and
 the right is dead/healthy. If the memory line spikes up and down rapidly, it could
 indicate memory thrashing. In those situations, it is a good idea to profile the
 application with Borland OptimizeIt or JProbe. What you want to see is a regular
 pattern for load, memory and threads. Any erratic behavior usually indicates poor
 performance or a bug of some sort.</p>

 </section>

 </body>
 </document>
	<?xml version="1.0"?>
	<!--
	Licensed to the Apache Software Foundation (ASF) under one or more
	contributor license agreements. See the NOTICE file distributed with
	this work for additional information regarding copyright ownership.
	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.
	See the License for the specific language governing permissions and
	limitations under the License.
	-->
	<!DOCTYPE document
	[
	<!ENTITY sect-num '12'>
	]>
	<document prev="build-jms-topic-test-plan.html" next="listeners.html" id="$Id$">

	<properties>
	<title>User's Manual: Building a Monitor Test Plan (REMOVED since JMeter 3.2)</title>
	</properties>

	<body>

	<section name="&sect-num;. Building a Monitor Test Plan (REMOVED since JMeter 3.2)" anchor="building">
	<note>Note this feature is deprecated since JMeter 3.1</note>
	<p>In this section, you will learn how to create a
	<a href="build-test-plan.html">Test Plan</a> to monitor webservers. Monitors
	are useful for a stress testing and system management. Used with stress
	testing, the monitor provides additional information about server performance.
	It also makes it easier to see the relationship between server performance
	and response time on the client side. As a system administration tool, the
	monitor provides an easy way to monitor multiple servers from one console.
	The monitor was designed to work with the status servlet in Tomcat 5. In
	theory, any servlet container that supports JMX (Java Management Extension)
	can port the status servlet to provide the same information.</p>
	<p>For those who want to use the monitor with other servlet or EJB containers,
	Tomcat's status servlet should work with other containers for the memory
	statistics without any modifications. To get thread information, you will
	need to change the MBeanServer lookup to retrieve the correct MBeans.</p>

	</section>

	<section name="&sect-num;.1 Adding A Server" anchor="adding_server">
	<p>The first step is to add a <a href="test_plan.html#thread_group">Thread Group</a>
	element. The Thread Group tells JMeter the number of threads you want. Always use
	<code>1</code>, since we are using JMeter as a monitor. This is very important for those not
	familiar with server monitors. As a general rule, using multiple threads for a
	single server is bad and can create significant stress.
	</p>

	<p>Go ahead and add the ThreadGroup element by first selecting the Test Plan,
	clicking your right mouse button to get the <menuchoice><guimenuitem>Add</guimenuitem></menuchoice> menu, and then select
	<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>ThreadGroup</guimenuitem>
	</menuchoice>.</p>

	<p>You should now see the Thread Group element under Test Plan. If you do not
	see the element, "expand" the Test Plan tree by clicking on the Test Plan element.</p>

	<figure image="webtest/threadgroup.png">
	Figure &sect-num;.1. Thread Group with Default Values</figure>

	<p>Change the loop count to forever (or some large number) so that enough samples are generated.</p>

	</section>

	<section name="&sect-num;.2 HTTP Auth Manager" anchor="adding_auth">
	<p>Add the <complink name="HTTP Authorization Manager"/> to the Thread Group element
	(<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>Config element</guimenuitem>
	<guimenuitem>HTTP Authorization Manager</guimenuitem>
	</menuchoice>). Enter the username
	and password for your webserver.
	<note>Important note: the monitor only works with
	Tomcat5 build 5.0.19 and newer. For instructions on how to setup Tomcat, please
	refer to tomcat 5 documentation.
	</note>
	</p>
	<ol>
	<li> leave the base URL blank</li>
	<li> enter the username</li>
	<li> enter the password</li>
	</ol>
	</section>

	<section name="&sect-num;.3 Adding HTTP Request" anchor="adding_request">

	<p>Add the <complink name="HTTP Request"/> to the Thread Group element
	(<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>Sampler</guimenuitem>
	<guimenuitem>HTTP Request</guimenuitem>
	</menuchoice>). Then, select the HTTP Request element
	in the tree and edit the following properties):
	<ol>
	<li>Change the Name field to "<code>Server Status</code>".</li>
	<li>Enter the IP address or Hostname</li>
	<li>Enter the port number</li>
	<li>Set the Path field to "<code>/manager/status</code>" if you're using Tomcat.</li>
	<li>Add a request parameter named "<code>XML</code>" in uppercase. Give it a value of
	"<code>true</code>" in lowercase.</li>
	<li>Check "<code>Use as Monitor</code>" at the bottom of the sampler</li>
	</ol>
	</p>

	</section>

	<section name="&sect-num;.4 Adding Constant Timer" anchor="adding_timer">

	<p>Add a timer to this thread group
	(<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>Timer</guimenuitem>
	<guimenuitem>Constant Timer</guimenuitem>
	</menuchoice>).
	Enter <code>5000</code> milliseconds in the "<code>Thread Delay</code>" box. In general, using intervals shorter
	than 5 seconds will add stress to your server. Find out what is an acceptable interval
	before you deploy the monitor in your production environment.</p>

	</section>

	<section name="&sect-num;.5 Adding a Listener to Store the Results" anchor="adding_listener">
	<p>If you want to save the raw results from the server, add a simple data
	<a href="component_reference.html#listeners">Listener</a>. If you want to save the
	calculated statistics, enter a filename in the listener. If you want to save both
	the raw data and statistics, make sure you use different filenames.</p>

	<p>Select the thread group element and add a <complink name="Simple Data Writer"/> listener
	(<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>Listener</guimenuitem>
	<guimenuitem>Simple Data Writer</guimenuitem>
	</menuchoice>). Next, you need to specify a directory
	and filename of the output file. You can either type it into the filename field, or
	select the Browse button and browse to a directory and then enter a filename.</p>

	</section>

	<section name="&sect-num;.6 Adding Monitor Results" anchor="add_monitor_listener">

	<p>Add the <a href="component_reference.html#listeners">Listener</a> by selecting the
	test plan element
	(<menuchoice>
	<guimenuitem>Add</guimenuitem>
	<guimenuitem>Listener</guimenuitem>
	<guimenuitem>Monitor Results</guimenuitem>
	</menuchoice>).
	</p><p>
	By default, the Listener will select the results from the first connector in the sample response.
	The Connector prefix field can be used to select a different connector.
	If specified, the Listener will choose the first connector which matches the prefix.
	If no match is found, then the first connector is selected.
	</p>
	<p>There are two tabs in
	the monitor results listener. The first is the "<code>Health</code>", which displays the status of
	the last sample the monitor received. The second tab is "<code>Performance</code>", which shows a
	historical view of the server's performance.
	</p>

	<figure image="monitor_health.png"/>
	<p>A quick note about how health is calculated. Typically, a server will crash if
	it runs out of memory, or reached the maximum number of threads. In the case of
	Tomcat 5, once the threads are maxed out, requests are placed in a queue until a
	thread is available. The relative importance of threads vary between containers, so
	the current implementation uses 50/50 to be conservative. A container that is more
	efficient with thread management might not see any performance degradation, but
	the used memory definitely will show an impact.</p>
	<figure image="monitor_screencap.png"/>
	<p>The performance graph shows four different lines. The free memory line shows how
	much free memory is left in the current allocated block. Tomcat 5 returns the maximum
	memory, but it is not graphed. In a well tuned environment, the server should never
	reach the maximum memory.</p>
	<p>Note the graph has captions on both sides of the graph. On the left is percent and
	the right is dead/healthy. If the memory line spikes up and down rapidly, it could
	indicate memory thrashing. In those situations, it is a good idea to profile the
	application with Borland OptimizeIt or JProbe. What you want to see is a regular
	pattern for load, memory and threads. Any erratic behavior usually indicates poor
	performance or a bug of some sort.</p>

	</section>

	</body>
	</document>