Detailed Diagnostics

By reporting detailed diagnostics on transaction responsiveness and errors, eG Enterprise not only points you to the slow/stalled/error transaction URLs, but also reveals what could be causing the slowness/errors.

Figure 1 reveals detailed diagnosis of the Slow transactions percentage measure of the Java Business Transactions test.

Figure 1 : Detailed diagnosis of the Slow transactions percentage measure of the Java Business Transactions test

The detailed diagnosis reveals the individual transaction URLs in the grouped URL that users requested for, the total response time of each transaction, the client (remote host) from which each transaction request was received, the thread executing the transaction, and the query string of the transaction URL.

The per-transaction response time displayed in Figure 1 includes the following:

  • The total time for which the transaction request was processed by the target JVM and by other BTM-enabled JVMs in the transaction path thereafter, until the time the response for that transaction request was sent out by the target JVM; 
  • The time taken by external calls (SQL query / HTTP / JMX / Java / JMS / SAP JCO / async) to other JVMs or backends in the transaction path;

Additionally, the overall experience of the users with each transaction – whether it is slow, stalled, or error - is also revealed in the REQUEST PROCESSING TIME column. Furthermore, the HTTP headers, cookies, the HTTP status code returned by the monitored node in response to the transaction request, and the type of HTTP method invoked by the transaction on that node are also revealed. In addition, the following are displayed as part of detailed diagnostics:

  • How much time each transaction used the CPU;
  • How much time was every transaction blocked;
  • How much time did each transaction spend waiting;

CPU-intensive transactions, blocked transactions, and waiting transactions of the chosen pattern can thus be isolated. Also, for the Slow or Stalled transactions, this information will help you determine the probable cause for the transaction slowness - is it because the transactions were blocked for too long and could not execute? or is it because the transactions were waiting for too long a time to continue execution?

The per-transaction statistics are also sorted in the descending order of the transaction response time, starting with the slowest transaction and ending with the healthiest one. In the event that the Avg response time of a grouped URL registers an abnormally high value, you can use these detailed metrics to quickly and accurately identify the exact transaction in the group that is significantly contributing to the poor user experience with the group.

Besides the above, the detailed diagnosis also includes two columns, namely - User Name and Business Context.By default, these two columns will not display any values. This has been done so that administrators can use these columns to display any additional information that they deem useful for troubleshooting transaction slowness. For instance, administrators can configure eG Enterprise to capture the name of the user who initiated each transaction and display the same in the User Name column for every transaction URL in the Detailed Diagnosis page. Likewise, administrators can also tweak eG Enterprise to capture and display information such as fetch type, class name, method name, method signature, session attribute name, URL pattern, etc. against Business Context. Such custom information can also be captured for specific transaction URLs or URL patterns alone. To know how this can be achieved, refer to the Configuring User Name and Business Context topic.

Detailed diagnostics are also available for the Slow transaction percentage, Stalled transaction percentage, and Error transaction percentage measures of the Java Business Transactions test. With the help of these detailed measures, you will be able to quickly and accurately identify the slow, stalled, and error transactions in a grouped URL.

Once a slow/stalled transaction is revealed, the next question is what is causing the transaction to slowdown. Transaction responsiveness can be impacted by any of the following factors:

  • An inefficient database query run by the target JVM node;
  • In a multi-JVM environment, a time-consuming POJO / non-POJO method called by any JVM node;
  • A poorly responsiveness remote service call made by the target JVM node;

With the help of illustrated examples, the links below describe how drill-downs from the detailed diagnostics enable accurate isolation of the root-cause of a transaction slowdown / errors in a transaction.