build-monitor-test-plan.xml

<?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 '13'>
]>
<document prev="build-jms-topic-test-plan.html" next="listeners.html" id="$Id: build-monitor-test-plan.xml 1175606 2011-09-25 22:28:22Z sebb $">

<properties>
  <title>User's Manual: Building a Monitor Test Plan</title>
</properties>

<body>

<section name="&sect-num;. Building a Monitor Test Plan" anchor="building">
<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
1, 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 Add menu, and then select
Add --&gt; ThreadGroup.</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
(Add --&gt; Config element --&gt; HTTP Authorization Manager). Enter the username
and password for your webserver. 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.</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
(Add --&gt; Sampler --&gt; HTTP Request). Then, select the HTTP Request element
in the tree and edit the following properties):
<ol>
<li>Change the Name field to "Server Status".</li>
<li>Enter the IP address or Hostname</li>
<li>Enter the port number</li>
<li>Set the Path field to "/manager/status" if you're using Tomcat.</li>
<li>Add a request parameter named "XML" in uppercase. Give it a value of
"true" in lowercase.</li>
<li>Check "Use as Monitor" 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 (Add --&gt; Timer --&gt; Constant Timer).
Enter 5000 milliseconds in the "Thread Delay" 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
(Add --&gt; Listener --&gt; Simple Data Writer).  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 (Add --&gt; Listener -- &gt; Monitor Results).
<br></br>
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 "Health", which displays the status of
the last sample the monitor received. The second tab is "Performance", 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 for 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 '13'>
	]>
	<document prev="build-jms-topic-test-plan.html" next="listeners.html" id="$Id: build-monitor-test-plan.xml 1175606 2011-09-25 22:28:22Z sebb $">

	<properties>
	<title>User's Manual: Building a Monitor Test Plan</title>
	</properties>

	<body>

	<section name="&sect-num;. Building a Monitor Test Plan" anchor="building">
	<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
	1, 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 Add menu, and then select
	Add --> ThreadGroup.</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
	(Add --> Config element --> HTTP Authorization Manager). Enter the username
	and password for your webserver. 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.</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
	(Add --> Sampler --> HTTP Request). Then, select the HTTP Request element
	in the tree and edit the following properties):
	<ol>
	<li>Change the Name field to "Server Status".</li>
	<li>Enter the IP address or Hostname</li>
	<li>Enter the port number</li>
	<li>Set the Path field to "/manager/status" if you're using Tomcat.</li>
	<li>Add a request parameter named "XML" in uppercase. Give it a value of
	"true" in lowercase.</li>
	<li>Check "Use as Monitor" 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 (Add --> Timer --> Constant Timer).
	Enter 5000 milliseconds in the "Thread Delay" 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
	(Add --> Listener --> Simple Data Writer). 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 (Add --> Listener -- > Monitor Results).
	<br></br>
	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 "Health", which displays the status of
	the last sample the monitor received. The second tab is "Performance", 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 for 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>