Java Application Response Time
Measurement
Use
The Java Application Response Time Measurement (JARM) is a method for collecting response time data from Java applications. The data delivers an overview of components passed by a thread and the time left in the corresponding component. The JARM displays not only the response time, but also the user who sent the request and the amount of data that was transferred.
This function is designed to allow performance measurements in productive systems and to identify areas that cause problems.
The JARM data is shown in the Performance Tracing service of the J2EE Engine Visual Administrator tool.
When you start the JARM runtime, no data is displayed. You have to use the Refresh option to view the latest JARM data. The data is presented in different views. For more information, see JARM Runtime Views.
The JARM data is automatically mapped to the CCMS monitoring infrastructure. The data can be displayed in the CCMS alert monitor (Transaction RZ20) under SAP J2EE Monitor Templates → Engines → <your system> → Performance.
Not all of the data is transferred to CCMS because of its large amount. Therefore, only the data shown in the Monitoring Service → Root → Performance→ Application Responsetime is transferred.
Features
The purpose of this monitoring is to give an overview about the status of the Java system. This includes the following topics:
· Top <n> Display – the most important requests are shown selected by different criteria such as response time or the amount of transferred data. Additionally, the control flow and the costs of the components processed for each request is shown.
· Accumulation of Data – average data for components or users such as execution time, data transfer, and so on.
· Thread Overview – an overview about the current usage of threads by the Java application is given. It indicates which threads are active and which components are currently involved.
Data Collection
At runtime of a request, the following data is collected as a result of the API calls:
· the user
· for each involved thread, you can see which request, component, [action] is currently being processed
· a request graph is built that collects all the calls belonging to one request
· the amount of transferred data
At the end of a request the request graph is put into the ‘finished request list’, which is processed asynchronously when the data is condensed.
Get / Reset Monitored Data
The data that was collected during request processing is condensed via an asynchronous thread. This thread works through the finished request list and does the following updates:
· Accumulation of Data
Here you can think of average data for requests, components or users such as execution time, data transfer, and so on.
For requests the accumulation is done for all of them, which means there is no request summary by name or any other criterion. A summary is created for each component.
· TOP <n> Lists
The most expensive requests and components are shown selected by different criteria such as response time or amount of transferred data.
The data of those requests that are not in the “Top” lists is deleted by the condense thread.
The data already collected and condensed can be deleted by the Reset function. You can delete everything, or just the request, component or user data.
See also:
Switching the JARM Monitoring On and Off
Limiting the Number of Components Per Request
Java Application Response Time Measurement (JARM) properties in the Reference Manual