| Measurement |
Description |
Measurement Unit |
Interpretation |
| All_urls_count |
Indicates the total number of requests received for transactions of this pattern during the last measurement period. |
Number |
By comparing the value of this measure across transaction patterns, you can identify the most popular transaction patterns. Using the detailed diagnosis of this measure, you can then figure out which specific transactions of that pattern are most requested. |
| All_urls_avg_time |
Indicates the average time taken by the transactions of this pattern to complete execution. |
Msecs |
Compare the value of this measure across patterns to isolate the type of transactions that were taking too long to execute. You can then use the detailed diagnosis of the All transactions measure of that group to know how much time each transaction in that group took to execute. This will lead you to the slowest transaction. |
| Healthy_trans_count |
Indicates the number of healthy transactions of this pattern. |
Number |
|
| Healthy_percentage |
Indicates what percentage of the total number of transactions of this pattern is healthy. |
Percent |
To know which are the healthy transactions, use the detailed diagnosis of this measure. |
| Slow_urls_count |
Indicates the number of transactions of this pattern that were slow during the last measurement period. |
Number |
This measure will report the number of transactions with a response time higher than the configured SLOW TRANSACTION CUTOFF (MS).
A high value is a cause for concern, as too many slow transactions means that user experience with the web application is poor. |
| Slow_urls_avg_time |
Indicates the average time taken by the slow transactions of this pattern to execute. |
Msecs |
|
| Slow_percentage |
Indicates what percentage of the total number of transactions of this pattern is currently slow. |
Percent |
Use the detailed diagnosis of this measure to know which precise transactions of a pattern are slow. You can drill down from a slow transaction to know what is causing the slowness. |
| Error_urls_count |
Indicates the number of transactions of this pattern that experienced errors during the last measurement period. |
Number |
A high value is a cause for concern, as too many error transactions to a web application can significantly damage the user experience with that application. |
| Error_urls_avg_time |
Indicates the average duration for which the transactions of this pattern were processed before an error condition was detected. |
Msecs |
The value of this measure will help you discern if error transactions were also slow. |
| Error_percentage |
Indicates what percentage of the total number of transactions of this pattern is experiencing errors. |
Percent |
Use the detailed diagnosis of this measure to isolate the error transactions. You can even drill down from an error transaction in the detailed diagnosis to determine the cause of the error. |
| Stalled_urls_count |
Indicates the number of transactions of this pattern that were stalled during the last measurement period. |
Number |
This measure will report the number of transactions with a response time higher than the configured STALLED TRANSACTION CUTOFF (MS).
A high value is a cause for concern, as too many stalled transactions means that user experience with the web application is poor. |
| Stalled_urls_avg_time |
Indicates the average time taken by the stalled transactions of this pattern to execute. |
Msecs |
|
| Stalled_percentage |
Indicates what percentage of the total number of transactions of this pattern is stalling. |
Percent |
Use the detailed diagnosis of this measure to know which precise transactions of a pattern are stalled. You can drill down from a stalled transaction to know what is causing that transaction to stall. |
| Slow_sql_count |
Indicates the number of slow SQL queries that were executed by the transactions of this pattern during the last measurement period. |
Number |
|
| Slow_sql_avg_time |
Indicates the average execution time of the slow SQL queries that were run by the transactions of this pattern. |
Msecs |
If there are too many slow transactions of a pattern, you may want to check the value of this measure for that pattern to figure out if query execution is slowing down the transactions.
Use the detailed diagnosis of the Slow transactions measure to identify the precise slow transaction. Then, drill down from that slow transaction to confirm whether/not database queries have contributed to the slowness. Deep-diving into the queries will reveal the slowest queries and their impact on the execution time of the transaction. |
| Cpu_time |
Indicates the average time for which transactions of this pattern were utilizing the CPU. |
Msecs |
Compare the value of this measure across transaction patterns to accurately identify the CPU-intensive transaction patterns.
For the Summary descriptor, this measure will report the average time for which all the transactions on the target JVM used the CPU.
Note:
This measure is reported only under the following circumstances:
The ENABLE THREAD CPU MONITORING flag of this test is set to Yes;
The target application server's JVM implementation supports CPU time monitoring of threads; to verify JVM support for CPU time monitoring, use the procedure described below:
Login to the target application server.
Open jconsole.
Switch to the MBeans tab page in the jconsole.
When the page appears, expand the java.lang node in the tree-structure of the left panel and click the Attributes sub-node. If you browse the list of attributes that then appear in the right panel, you will find the ThreadContentionMonitoringSupported attribute. If this attribute is set to yes, it means that the JVM supports contention monitoring. Likewise, look for the ThreadCpuTimeSupported attribute in that list, and once found, check its status. If this attribute is set to yes, it means that the JVM supports CPU time monitoring.
|
| Block_time |
Indicates the average duration for which transactions of this pattern were blocked and could not execute. |
Msecs |
If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not prolonged blocking is causing transactions of that pattern to slow down or stall.
For the Summary descriptor, this measure will report the average time for which all the transactions on the target JVM were blocked.
Note:
This measure is reported only under the following circumstances:
The ENABLE THREAD CONTENTION MONITORING flag of this test is set to Yes;
The target application server's JVM implementation supports thread contention monitoring; to verify JVM support for thread contention monitoring, use the procedure described below:
Login to the target application server.
Open jconsole.
Switch to the MBeans tab page in the jconsole.
When the page appears, expand the java.lang node in the tree-structure of the left panel and click the Attributes sub-node. If you browse the list of attributes that then appear in the right panel, you will find the ThreadContentionMonitoringSupported attribute. If this attribute is set to yes, it means that the JVM supports contention monitoring. Likewise, look for the ThreadCpuTimeSupported attribute in that list, and once found, check its status. If this attribute is set to yes, it means that the JVM supports CPU time monitoring.
|
| Wait_time |
Indicates the average duration for which transactions of this pattern were waiting before they resumed execution. |
Msecs |
If the Avg response time for any transaction pattern is very high, you may want to check the value of this measure for that pattern. This will help you figure out whether/not a very high waiting time is what is causing the transactions to slow down/stall.
For the Summary descriptor, this measure will report the average time for which all the transactions on the target JVM were waiting.
Note:
This measure is reported only under the following circumstances:
The ENABLE THREAD CONTENTION MONITORING flag of this test is set to Yes;
The target application server's JVM implementation supports thread contention monitoring; to verify JVM support for thread contention monitoring, use the procedure described below:
Login to the target application server.
Open jconsole.
Switch to the MBeans tab page in the jconsole.
When the page appears, expand the java.lang node in the tree-structure of the left panel and click the Attributes sub-node. If you browse the list of attributes that then appear in the right panel, you will find the ThreadContentionMonitoringSupported attribute. If this attribute is set to yes, it means that the JVM supports contention monitoring. Likewise, look for the ThreadCpuTimeSupported attribute in that list, and once found, check its status. If this attribute is set to yes, it means that the JVM supports CPU time monitoring.
|
| Call_per_minutes |
Indicates the number of transactions of this pattern that are executed per minute. |
Number |
For the Summary descriptor, this measure will report the total number of transactions that were executed per minute. This is a good indicator of the transaction processing ability of the target application server. |
| Error_call_per_minutes |
Indicates the number of error transactions of this pattern that are executed per minute. |
Number |
A very low value is desired for this measure.
Compare the value of this measure across transaction patterns to find that pattern of transactions that is experiencing errors frequently.
For the Summary descriptor, this measure will report the total number of error transactions that were executed per minute. |