by selecting the
test plan element (Add --> Listener -- > Monitor Results).
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.
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.
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.
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.
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.