Monitoring Performance and Resource Usage 

You can monitor the performance of the system and the usage of the system resources, and the status of the manager and services of the J2EE Engine from the central system. You can monitor the performance above all using the statistical records that the system writes. Use transaction ST03G of your central system to display the statistical records.

You can display the system resources and the data provided by the managers and services in the status monitors of the Monitor Service in the Visual Administrator. This data is transferred to the central system and monitored with the Alert Monitor, transaction RZ20.

To only monitor the performance and resource usage of your Java system, it is recommended that you use the NWA. For more information, see Java System Reports.

However, if you need to do some changes in your performance analysis system, you can continue with this topic.

Performance

Prerequisites

·        The J2EE Engine is delivering statistics records to the central monitoring system using the SAPCCMSR agent.

·        The DSR collector job SAP_COLLECTOR_FOR_NONE_R3_STAT is scheduled in the central monitoring system.

Monitoring the General Performance

The performance of the J2EE Engine and of the deployed applications is displayed as statistics, known as Distributed Statistics Records (DSR) in the Global Workload Monitor (transaction ST03G). The data can be called in different modes:

·        As a workload overview for the day, the week, or the month

·        As action, time, or user profiles, broken down by the individual services:

¡        EJB request

¡        Web request

¡        Security

¡        System

·        DSR Administration

·        Workload for the last few minutes

 

It is not possible to set alerts for statistical values. It is therefore necessary and important to check the performance values at regular intervals.

The interpretation of the performance data is based to a large extent on experience by observing your own system and, for example, on perceived adequate response time duration, depending on the size and complexity of the application called, the number of database accesses, and the quantity of transported data.

 

You can, for example, compare the response times for today with the response times for previous days.

Use the hit lists (top response time, top call time) and the response time distribution to check whether and how problems occurred.For information about how you can identify applications with errors or that are not performing well, see the example Performance Analysis with DSRs.

Activating the Performance Trace

The performance trace is deactivated as a basic principle to avoid generating additional and unnecessary workload. You should only activate it if a problem has occurred. Activate the performance trace in the DSR service of the Visual Administrator for the modules that can be useful for investigating the problem that has occurred. You can display the trace data that is written in transaction STATTRACE.

Advanced Analysis Steps for Applications Not Performing Well

·        If the problem has occurred for an SAP application:

¡        Activate and analyze the single activity trace

¡        Consult the documentation for the SAP application

·        If your system is a development system and not a production system, you can use application tracing to investigate the application to method level.

Do not use application tracing in production systems, since you must stop and restart the application to do so.

Status Monitors of the Monitor Service

The vital values for the individual managers and services of the J2EE Engine, such as memory usage, pool utilization, and queue sizes are displayed in the Monitor Service of the Visual Administrator with alert colors using the “traffic light system”.

 

 

The data displayed here is transferred to the CCMS of the central system by the SAPCCMSR agent with the option –J2EE and is displayed in the alert monitor (transaction RZ20). You can also set up notifications in the case of alerts and auto-reaction methods here.

For information about identifying the problems that have occurred, see the reference manual for the manager or the service that is displaying the error.

 

Example: Reacting to an Alert in the Status Monitor

If an alert occurs in the Pool Manager monitor, which displays that there are insufficient byte objects of a particular size available, go to the Pool Manager of the server and increase the maximum number of entries.

 

Before you make changes to the configurations, you should ensure that you understand the dependencies of the changes. For example, if you increase pools, additional memory is usually allocated. Increasing the number of threads accepted in the HTTP Provider leads to a greater workload in the system and the respective applications, and so on.