Show TOC

Procedure documentationWorkload Analysis

 

The Workload Analysis of Root Cause Analysis gives an overview of the performance parameters of your complete solution. Using this information, you can check for a generic performance bottleneck in a system landscape. The performance bottleneck is then analyzed using the component−specific tools that are available for ABAP workload, J2EE workload, and operating system resource analysis.

Different monitors and analysis tools provide you with key performance indicators for the different components. Most commonly, there is an initial check of the overall response times to check the overall workload. For a more detailed analysis, the portfolio view helps you to identify bottlenecks by correlating the average response time of the system with accumulated high response time. This indicates a performance bottleneck (high workload combined with high average response time).

Component-specific key performance indicators (KPI) are available for each separate component. You can check for deviations from average values.

Prerequisites

You have the corresponding authorizations for the Root Cause Analysis work center.

Procedure

To start a workload analysis, go to the area Root Cause Analysis:

  1. In the navigation area, choose End to End Analysis.

  2. In the Detailed Selection area, select one or more systems for which you want to perform the analysis.

  3. In the header area of the Detailed Selection list, click the push button Workload Analysis to launch the workload analysis application.

The overview section of the end-to-end workload analysis tool shows you the key performance indicators of the solution in graphical and tabular form. You can customize the time frame of the displayed data in the top section of the tool. On the right side, you can find the numeric values for the key performance indicators for each system.

The standard display type is the Time Profile for the graphical display. The aggregated Day Profile is always displayed, regardless of the time frame chosen for display. For example, when you display the previous week, the graph displays from 0:00 to 24:00 on the x-axis, and therefore displays the average hourly values for the previous week.

The display allows you to quickly identify workload peaks, which are directly correlated to the typical working hours of your system. Unless the users in the monitored system operate globally, one would expect a pronounced daily pattern exhibiting peaks during the day and a relatively low load at night. The time profile is available for both the average response time and the accumulated response time.

The diagram type Portfolio displays the average response time on the y-axis and the hour of day on the x-axis. The size of the markers represents the accumulated response time. Critical situations have high and large markers.

For a performance analysis, scan for parameters that have both high average response times as well as large accumulated response times. Large accumulated response times have the largest overall impact on the performance of a system. These two parameters are directly proportional:

Accumulated Response Time = Average Response Time × Number of Executions

Note Note

The average response time for the metric data type Dialog is always displayed in milliseconds, whereas the accumulated response time is always displayed in seconds.

End of the note.

The diagram type Scatter displays the data with the average response time on the x-axis and the accumulated response time on the y-axis. Similar to the Time Profile, data points are displayed as hourly average values for the selected time frame. You can consider the diagram to be divided into four quadrants, distinguishing between low and high average response times on the x-axis and low and high accumulated response times on the y-axis. The top right quadrant with both high average response time and high accumulated response time is therefore the critical quadrant. Values in this quadrant have the greatest impact on the system they were measured on.

Example Example

In a linear response time regime, the average response time does not directly depend on the number of executions (that is, the number of users). Therefore, data markers should be scattered around a constant average response time in a line parallel to the y-axis. If a high load situation drives the system to non-linear behavior, the data markers show a deviation from this line and data points may move to the critical quadrant, where the scattered points are no longer parallel to the y-axis.

End of the example.

In addition to the overview tab, you can select individual tabs to analyze the application-specific workload data of each system of your solution.

Result

You displayed data for which you can perform further analyses.