Stack trace of the transactions reported by the Java Transactions Test

The detailed diagnosis of the Slow transactions response time measure lists the top-10 (by default) transactions of a configured pattern that have violated the response time threshold set using the SLOW URL THRESHOLD parameter of this test. Against each transaction, the date/time at which the transaction was initiated/requested will be displayed. Besides the request date/time, the remote host from which the transaction request was received and the total response time of the transaction will also be reported. This response time is the sum total of the response times of each of the top methods (in terms of time taken for execution) invoked by that transaction. To compute this sum total, the test considers only those methods with a response time value that is higher than the threshold limit configured against the METHOD EXEC CUTOFF parameter.

In the detailed diagnosis, the transactions will typically be arranged in the descending order of the total response time; this way, you would be able to easily spot the slowest transaction. To know what caused the transaction to be slow, you can take a look at the SUBCOMPONENT DETAILS column of the detailed diagnosis. Here, the time spent by the transaction at each of the Java layers/Java sub-components (FILTER, STRUTS, SERVLETS, JSPS, POJOS, SQL, JDBC,etc.) will be listed, thus leading you to the exact layer/sub-component where the slowdown occurred.

You can even perform detailed method-level analysis to isolate the methods taking too long to execute. For this, click on the URL Tree link. The Method Level Breakup section in the At-A-Glance tab page will then appear. In the left panel of the page, you will find the list of transactions that match a configured pattern; these transactions will be sorted in the descending order of their Total Response Time (by default). This is indicated by the Total Response Time option chosen by default from the Sort by list in the page. If you select a transaction from the left panel, an At-A-Glance tab page will open by default in the right panel, providing quick, yet deep insights into the performance of the chosen transaction and the reasons for its slowness. This tab page begins by displaying the URL of the chosen transaction, the total Response time of the transaction, the time at which the transaction was last requested, and the Remote Host from which the request was received.

If the Response time appears to be very high, then you can take a look at the Method Level Breakup section to figure out which method called by which layer/sub-component (such as FILTER, STRUTS, SERVLETS, JSPS, POJOS, SQL, JDBC, etc.) could have caused the slowdown. This section provides a horizontal bar graph, which reveals the percentage of time for which the chosen transaction spent executing each of the top methods (in terms of execution time) invoked by it. The legend below clearly indicates the top methods and the layer/sub-component that invoked each method. Against every method, the number of times that method was invoked in the Measurement Time, the Duration (in Secs) for which the method executed, and the percentage of the total execution time of the transaction for which the method was in execution will be displayed, thus quickly pointing you to those methods that may have contributed to the slowdown. The methods displayed here and featured in the bar graph depend upon the METHOD EXEC CUTOFF configuration of this test - in other words, only those methods with an execution duration that exceeds the threshold limit configured against METHOD EXEC CUTOFF will be displayed in the Method Level Breakup section.

While the Method Level Breakup section provides method-level insights into responsiveness, for a sub-component or layer level breakup of responsiveness scroll down the At-A-Glance tab to view the Component Level Breakup section. Using this horizontal bar graph, you can quickly tell where - i.e., at which Java layer/sub-component - the transaction spent the maximum time. A quick glance at the graph's legend will reveal the layers/sub-components the transaction visited, the number of methods invoked by each layer/sub-component, the Duration (Secs) for which the transaction was processed at the layer/sub-component, and what Percentage of the total transaction response time was spent at the layer/sub-component.

Besides Java methods, where the target Java application interacts with the database, long-running SQL queries can also contribute to the poor responsiveness of a transaction. You can use the At-A-Glance tab page to determine whether the transaction interacts with the database or not, and if so, how healthy that interaction is. For this, scroll down the At-A-Glance tab page.

Upon scrolling, you will find query details below the Component Level Breakup section. All the SQL queries that the chosen transaction executes on the backend database will be listed here in the descending order of their Duration. Corresponding to each query, you will be able to view the number of times that query was executed, the Duration for which it executed, and what percentage of the total transaction response time was spent in executing that query. A quick look at this tabulation would suffice to identify the query which executed for an abnormally long time on the database, causing the transaction's responsiveness to suffer. For a detailed query description, click on the query. Detailed description of the query will then pop up displaying the complete query and its execution duration.

This way, the At-A-Glance tab page allows you to analyze, at-a-glance, all the factors that can influence transaction response time - be it Java methods, Java layers/sub-components, and SQL queries - and enables you to quickly diagnose the source of a transaction slowdown. If, for instance, you figure out that a particular Java method is responsible for the slowdown, you can zoom into the performance of the ‘suspect method’ by clicking on that method in the Method Level Breakup section of the At-A-Glance tab page. This will automatically lead you to the Trace tab page, where all invocations of the chosen method will be highlighted.

Typically, clicking on the Trace tab page will list all the methods invoked by the chosen transaction, starting with the very first method. Methods and sub-methods (a method invoked within a method) are arranged in a tree-structure, which can be expanded or collapsed at will. To view the sub-methods within a method, click on the arrow icon that precedes that method in the Trace tab page. Likewise, to collapse a tree, click once again on the arrow icon. Using the tree-structure, you can easily trace the sequence in which methods are invoked by a transaction.

If a method is chosen for analysis from the Method Level Breakup section of the At-A-Glance tab page, the Trace tab page will automatically bring your attention to all invocations of that method by highlighting them. Likewise, if a layer/sub-component is clicked in the Component Level Breakup section of the At-A-Glance section, the Trace tab page will automatically appear, displaying all the methods invoked from the chosen layer/Java sub-component.

For every method, the Trace tab page displays a Request Processing bar, which will accurately indicate when, in the sequence of method invocations, the said method began execution and when it ended; with the help of this progress bar, you will be able to fairly judge the duration of the method, and also quickly tell whether any methods were called prior to the method in question. In addition, the Trace tab page will also display the time taken for a method to execute (Method Execution Time) and the percentage of the time the transaction spent in executing that method. The most time-consuming methods can thus be instantly isolated.

The Trace tab page also displays the Total Execution Time for each method - this value will be the same as the Method Execution Time for ‘stand-alone’ methods - i.e., methods without any sub-methods. In the case of methods with sub-methods however, the Total Execution Time will be the sum total of the Method Execution Time of each sub-method invoked within. This is because, a ‘parent’ method completes execution only when all its child/sub-methods finish executing.

With the help of the Trace tab page therefore, you can accurately trace the method that takes the longest to execute, when that method began execution, and which ‘parent method’ (if any) invoked the method.

Next, click on the SQL/Errors tab page. This tab page lists all the SQL queries the transaction executes on its backend database, and/or all the errors detected in the transaction's Java code. The query list is typically arranged in the descending order of the query execution Duration, and thus leads you to the long-running queries right away! You can even scrutinize the time-consuming query on-the-fly, and suggest improvements to your administrator instantly.

When displaying errors, the SQL/Error tab page does not display the error message alone, but displays the complete code block that could have caused the error to occur. By carefully scrutinizing the block, you can easily zero-in on the ‘exact line of code&gsquo; that could have forced the error - this means that besides pointing you to bugs in your code, the SQL/Error tab page also helps you initiate measures to fix the same.

This way, with the help of the three tab pages - At-A-Glance, Trace, and SQL/Error - you can effectively analyze and accurately diagnose the root-cause of slowdowns in transactions to your Java applications.

The detailed diagnosis of the Error transactions response time measure reveals the top-10 (by default) transactions, in terms of TOTAL RESPONSE TIME, that have encountered errors. To know the nature of the errors that occurred, click on the URL Tree icon in the detailed diagnosis page. This will lead you to the URL Tree window, which has already been elaborately discussed.