|
Measures reported by JavaTransactionsTest
When a user initiates a transaction to a Java-based web application, the transaction typically travels many layers before completing execution and sending out a response to the user.
Some of the key layers through which a Java transaction passes have been briefly mentioned below:
- Filter Layer: A filter is a program that runs on the server before the servlet or JSP page with which it is associated. All filters must implement javax.servlet.Filter. This interface comprises three methods: init, doFilter, and destroy.
- Servlet Layer: A servlet acts as an intermediary between the client and the server. As servlet modules run on the server, they can receive and respond to requests made by the client. If a servlet is designed to handle HTTP requests, it is called an HTTP Servlet.
- JSP Layer: Java Server Pages are an extension to the Java servlet technology. A JSP is translated into Java servlet before being run, and it processes HTTP requests and generates responses like any servlet. Translation occurs the first time the application is run.
- Struts Layer: The Struts Framework is a standard for developing well-architected Web applications. Based on the Model-View-Controller (MVC) design paradigm, it distinctly separates all three levels (Model, View, and Control).
A delay experienced by the transaction at any of the aforesaid layers can adversely impact the total response time of that transaction, thereby scarring the user experience with the web application. In addition, delays in JDBC connectivity and slowdowns in SQL query executions (if the application interacts with a database), bottlenecks in delivery of mails via the Java Mail API (if used), and any slow method calls, can also cause insufferable damage to the 'user-perceived' health of a web application.
The challenge here for administrators is to not just isolate the slow transactions, but to also accurately identify the 'exact layer' at which the transaction slowed down and why - is it owing to inefficent JSPs? poorly written servlets or struts? poor or the lack of any JDBC connectivity to the database? long running queries? inefficient API calls? or delays in accessing the POJO methods? The eG JTM Monitor provides administrators with answers to these questions!
With the help of the JavaTransactionsTest, the eG JTM Monitor traces the route a configured web transaction takes, and captures live the total responsiveness of the transaction and the response time at each layer en route. This way, the solution proactively detects transaction slowdowns, and also precisely points you to the layer causing it - is it the Filters layer? JSPs layer? Servlets layer? Struts layer? JDBC layer? SQL query layer? Java Mail API layer? or the POJO layer? In addition to revealing where (i.e., at which layer) a transaction slowed down, the solution also provides the following intelligent insights, on demand, making root-cause identification and resolution easier:
- A look at the methods that took too long to execute, thus leading you to those methods that may have contributed to the slowdown;
- Single-click access to each invocation of a chosen method, which provides pointers to when and where a method spent longer than desired;
- A quick glance at SQL queries and Java errors that may have impacted the responsiveness of the transaction;
Using these interesting pointers provided by the eG JTM Monitor, administrators can diagnose the root-cause of transaction slowdowns within minutes, rapidly plug the holes, and thus ensure that their critical web applications perform at peak capacity at all times!
Note:
If the value of any of the parameters of the JavaTransactionsTest test is changed at a later point in time, then the test will not report any metrics for the measurement cycle that immediately follows the change. For instance, say that the Java Transactions test has been configured to run every 10 minutes, and the last time the test executed was as at 10.30 AM. This means that the test will execute next at 10.40 AM. Now, if you make changes to the test parameters at say, 10.35 AM, no metrics will be reported by the test when it executes at 10.40 AM. However, subsequently, when the test executes again at 10.50 AM, it will report all metrics.
Before attempting to monitor Java transactions using the eG JTM Monitor, a set of configurations have to be performed. To know more about how to perform the configurations Click here
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| All_urls_count |
Indicates the total number of transactions of this pattern that the target application handled during the last measurement period. |
Number |
|
| All_urls_avg_time |
Indicates the average time taken by the transactions of this pattern to complete execution. |
Secs |
Compare the value of this measure across patterns to isolate the type of transactions that were taking too long to execute. You can then take a look at the values of the other measures to figure out where the transaction is spending too much time.
|
| 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 URL THRESHOLD.
A high value is a cause for concern, as too many slow transactions to an application can significantly damage the user experience with that application. |
| Slow_urls_avg_time |
Indicates the average time taken by the slow transactions of this pattern to execute. |
Secs |
Use the detailed diagnosis of this measure to know which transactions are slow. |
| 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-prone transactions to an 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. |
Secs |
Use the detailed diagnosis of this measure to isolate the error transactions. |
| Filter_count |
Indicates the number of filters that were accessed by the transactions of this pattern during the last measurement period. |
Number |
A filter is a program that runs on the server before the servlet or JSP page with which it is associated. |
| Filter_avg_time |
Indicates the average time spent by the transactions of this pattern at the Filters layer. |
Secs |
Typically, the init, doFilter, and destroy methods are called at the Filters layer. Issues in these method invocations can increase the time spent by a transaction at this layer.
Compare the value of this measure across patterns to identify the transaction pattern that spent the maximum time at the Filters layer.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Jsp_count |
Indicates the number of JSPs accessed by the transactions of this pattern during the last measurement period. |
Number |
|
| Jsp_avg_time |
Indicates the average time spent by the transactions of this pattern at the JSP layer. |
Secs |
Compare the value of this measure across patterns to identify the transaction pattern that spent the maximum time at the JSP layer.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| HttpServlet_count |
Indicates the number of HTTP servlets that were accessed by the transactions of this pattern during the last measurement period. |
Number |
|
| HttpServlet_avg_time |
Indicates the average time taken by the HTTP servlets for processing the HTTP requests of this pattern. |
Secs |
Badly written servlets can take too long to execute, and can hence obstruct the smooth execution of the dependent transactions.
By comparing the value of this measure across patterns, you can figure out which transaction pattern is spending the maximum time at the Servlets layer.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| GenericServlet_count |
Indicates the number of generic (non-HTTP) servlets that were accessed by the transactions of this pattern during the last measurement period. |
Number |
|
| GenericServlet_avg_time |
Indicates the average time taken by the generic (non-HTTP) servlets for processing transactions of this pattern. |
Secs |
Badly written servlets can take too long to execute, and can hence obstruct the smooth execution of the dependent transactions.
By comparing the value of this measure across patterns, you can figure out which transaction pattern is spending the maximum time at the Servlets layer.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Jdbc_count |
Indicates the number of JDBC statements that were executed by the transactions of this pattern during the last measurement period. |
Number |
The methods captured by the eG JTM Monitor from the Java class for the JDBC sub-component include: Commit(), rollback(..), close(), GetResultSet(), executeBatch(), cancel(), connect(String, Properties), getConnection(..), getPooledConnection(..) |
| Jdbc_avg_time |
Indicates the average time taken by the transactions of this pattern to execute JDBC statements. |
Secs |
By comparing the value of this measure across patterns, you can figure out which transaction pattern is taking the most time to execute JDBC queries.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Sql_count |
Indicates the number of SQL queries executed by the transactions of this pattern during the last measurement period. |
Number |
|
| Sql_avg_time |
Indicates the average time taken by the transactions of this pattern to execute SQL queries. |
Secs |
Inefficient queries can take too long to execute on the database, thereby significantly delaying the responsiveness of the dependent transactions. To know which transactions have been most impacted by such queries, compare the value of this measure across the transaction patterns.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Exceptions_count |
Indicates the number of exceptions encountered by the transactions of this pattern during the last measurement period. |
Number |
Ideally, the value of this measure should be 0. |
| Exceptions_avg_time |
Indicates the average time which the transactions of this pattern spent in handling exceptions. |
Secs |
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Struts_count |
Indicates the number of struts accessed by the transactions of this pattern during the last meaurement period. |
Number |
The Struts framework is a standard for developing well-architected Web applications. |
| Struts_avg_time |
Indicates the average time spent by the transactions of this pattern at the Struts layer. |
Secs |
If you compare the value of this measure across patterns, you can figure out which transaction pattern spent the maximum time at the Struts layer.
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Email_count |
Indicates the number of mails sent by the transactions of this pattern during the last measurement period, using the Java mail API. |
Number |
The eG JTM Monitor captures any mail that has been sent from the monitored application using Java Mail API. Mails sent using other APIs are ignored by the eG JTM Monitor. |
| Email_avg_time |
Indicates the average time taken by the transactions of this pattern to send mails using the Java mail API. |
Secs |
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
| Pojo_count |
Indicates the number of transactions of this pattern that accessed POJOs during the last measurement period. |
Number |
Plain Old Java Object (POJO) refers to a 'generic' method in JAVA Language. All methods that are not covered by any of the layers/components (eg., JSPs, Struts, Servlets, Filters, Exceptions, Queries, etc.) discussed above will be automatically included under POJO.
When reporting the number of POJO methods, the eG agent will consider only those methods with a response time value that is higher than the threshold limit configured against the METHOD EXEC CUTOFF parameter. |
| Pojo_avg_time |
Indicates the average time taken by the transactions of this pattern to access POJOs. |
Secs |
If one/more transactions of a pattern are found to be slow, then, you can compare the value of this measure with the other response time values reported by this test to determine where the slowdown actually occurred - at the filters layer, JSPs layer, servlets layer, struts layer, in exception handling, when executing JDBC/SQL queries, when sending Java mails, or when accessing POJOs. |
Note:
If the target server is running in a time zone different from the time zone preference of the user who is currently logged into the eG management console, then you are sure to notice significant discrepancies in the REQUEST TIME of the transactions displayed in the Detailed Diagnosis and the time at which the eG agent collected the detailed measures - i.e, the TIME display in the Detailed Diagnosis page
|