eG Help

The responsiveness of a transaction is the key determinant of user experience with that transaction; if response time increases, user experience deteriorates. To make users happy, a Java business transaction should be rapidly processed by each of the JVM nodes in its path. Processing bottlenecks on a single JVM node can slowdown/stall an entire business transaction or can cause serious transaction errors. This in turn can badly scar the experience of users. To avoid this, administrators should promptly identify slow/stalled/errored transactions, isolate the JVM node on which the slowness/error occurred, and uncover what caused the aberration on that node - is it owing to SQL queries executed by the node? Or is it because of external calls - eg., async calls, SAP JCO calls, HTTP calls, etc. - made by that node? The BusinessTransTest test helps with this!

This test runs on a BTM-enabled JVM in an IT infrastructure, tracks all the transaction requests received by that JVM, and groups requests based on user-configured pattern specifications. For each transaction pattern, the test then computes and reports the average time taken by that JVM node to respond to the transaction requests of that pattern. In the process, the test identifies the slow/stalled transactions of that pattern, and reports the count of such transactions and their responsiveness. Detailed diagnostics provided by the test accurately pinpoint the exact transaction URLs that are slow/stalled, the total round-trip time of each transaction, and also indicate when such transaction requests were received by that node. The slowest transaction in the group can thus be identified.

Moreover, to enable administrators to figure out if the slowness can be attributed to a bottleneck in SQL query processing, the test also reports the average time the transactions of each pattern took to execute SQL queries. If a majority of the queries are slow, then the test will instantly capture the same and notify administrators.

Additionally, the test promptly alerts administrators to error transactions of each pattern. To know which are the error transactions, the detailed diagnosis capability of the test can be used.

This way, the test effortlessly measures the performance of each transaction to a JVM node, highlights transactions that are under-performing, and takes administrators close to the root-cause of poor transaction performance.

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. For the Summary descriptor, this measure will reveal the total number of transaction requests received by the target JVM during the last measurement period. This is a good indicator of the transaction workload on that JVM.
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. For the Summary descriptor, this measure will reveal the average responsiveness of all the transaction requests received by the target JVM during the last measurement period. An abnormally low value for this measure for the Summary descriptor could indicate a serious processing bottleneck on the target JVM.
Healthy_trans_count	Indicates the number of healthy transactions of this pattern.	Number	For the Summary descriptor, this measure will report the total number of healthy transactions on the target JVM.
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. For the Summary descriptor, this measure will report the overall percentage of healthy transactions on the target JVM.
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. For the Summary descriptor, this measure will report the total number of slow transactons on the target JVM. This is a good indicator of the processing powerof the target JVM.
Slow_urls_avg_time	Indicates the average time taken by the slow transactions of this pattern to execute.	Msecs	For the Summary descriptor, this measure will report the average response time of all the slow transactions on the target JVM.
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. For the Summary descriptor, this measure will report the overall percentage of slow transactions on the monitored JVM.
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. For the Summary descriptor, this measure will report the total number of error transactons on the target JVM. This is a good indicator of how error-prone the target JVM is.
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. For the Summary descriptor, this measure will report the average response time of all error transactions on the target JVM.
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. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target JVM that is currently experiencing errors.
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. For the Summary descriptor, this measure will report the total number of stalled transactons on the target JVM.
Stalled_urls_avg_time	Indicates the average time taken by the stalled transactions of this pattern to execute.	Msecs	For the Summary descriptor, this measure will report the average response time of all stalled transactions on the target JVM.
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. For the Summary descriptor, this measure will report the overall percentage of transactions of this pattern on the target JVM that is stalling.
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	For the Summary descriptor, this measure will report the total number of slow SQL queries executed by all transactions to the target JVM.
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_urls_count 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.