Measure your Application's Performance and Resource Consumption: Evaluate Statistics Records with Transaction STATS

[ManfredMensch]

Imagine that you have designed and implemented this great app your users have been waiting for. But if it is too slow, they will not like it. System administrators will hate it if its resource consumption is too high. How do you know ahead of time that your app offers great functions and also runs fast and lean? You use transaction STATS to evaluate statistics records associated with your application's executions.

In this blog post I explain how you obtain statistics records with high quality and how you analyze them with transaction STATS. In the best case, such an analysis proves that your app combines excellent single user performance with low resource consumption and is scalable. In all other situations, the analysis will indicate the bottleneck where optimizations shall be applied.

As owner and developer of transaction STATS I am more than happy to share tips and tricks that will help you to efficiently work with the tool and to obtain insights into your application's performance.
You can use STATS since SAP NetWeaver 7.40. I am continuously improving it and this blog post presents the tool’s state for SAP NetWeaver 7.57 as of late December 2021.

What are Statistics Records?

Statistics records are logs of activities performed in SAP NetWeaver Application Server for ABAP or on the ABAP platform. During the execution of any task by a work process in an ABAP instance, the SAP kernel collects header information to identify the task, and captures various measurements, like the task’s response time and total memory consumption. When the task ends, the gathered data is combined into a statistics record.  These records are stored chronologically in a file in the application server instance’s file system. Collecting statistics records is a technical feature of the ABAP runtime environment and requires no manual effort.

The measurements in these records provide useful insights into the performance and resource consumption of the application whose execution triggered the records’ capture. Especially helpful is the breakdown of the response times of the associated tasks into DB requests, ABAP processing, remote communication, or other contributors.

The value of your performance analysis depends on the quality of the underlying measurements. While the collection of data into the statistics records is performed autonomously by the SAP kernel, you need some preparation to ensure that the captured information accurately reflects the performance of the application.

1. Ensure that the test system you will use for the measurements is configured and customized correctly.


2. Verify that the test system is not under high load from concurrently running processes during your measurements


3. Carefully define the test scenario to be executed by your application. It must adequately represent the application’s behavior in production.


4. Provide a set of test data that is representative of your productive data. Only then will the business scenario execution resemble everyday use.


5. Execute the scenario a few times to fill the buffers and caches of all the involved components (e.g., DB cache, application server’s table buffer, web browser cache). Otherwise, your measurements will not be reproducible, but will be impaired by one-off effects that load data into these buffers and caches. It is then much harder to draw reliable conclusions.

After this preparation, you execute the measurement run, during which the SAP kernel writes the statistics records that you will use for the analysis.

How Do You Analyze Statistics Records?

To display the statistics records of your measurement run, you call transaction STATS. Its start screen (Fig. 1) consists of four areas, where you specify criteria for the subset of statistics records you want to view and analyze.

Figure 1: On the STATS start screen, you define filter conditions for the subset of statistics records you want to analyze, specify from where the records are retrieved, and select the layout of the data display.

In the topmost area, you determine the Monitoring Interval. By default, it extends 10 minutes into the past and 1 minute into the future. Records written during this period are displayed if they fulfill the conditions specified in the other areas of the start screen. Adjust this interval based on the start and end times of your measurement run so that STATS shows as few unrelated records as possible.

In the Record Filter area, you define additional criteria that the records must meet—for example, client, user, or lower thresholds for measurement data, such as response time or memory consumption. Be as specific and restrictive as possible, so that only records relevant for your investigation will be displayed.

By default, statistics records are read from all application instances of the system. In the Configuration section, you can change this to the local instance, or to any subset of instances within the current system. Restricting the statistics records retrieval to the instance (or instances) where the application was executed shortens the runtime of STATS. The option Include Statistics Records from Memory is selected by default, so that STATS will also process records that have not yet been flushed from the memory buffer into the file system.

Under Display Layout, select the domain you want to focus on and how the associated subset of key performance indicators (KPIs)—the captured data—will be arranged in the tabular display of statistics records. The Main KPIs layouts provide an initial overview with the most important data and is a good starting point.

What do You Learn from Statistics Records?

Fig. 2 shows the statistics record display based on the settings specified in the STATS start screen (Fig. 1).

Figure 2: Statistics records matching the criteria specified on the STATS start screen.
The list shows statistics records that correspond to the creation of a sales order with SAP GUI transaction VA01.

The table lists the selected statistics records in chronological order and contains their main KPIs. The header columns—shown with a blue background—uniquely link each record to the corresponding task that was executed by the work process. The data columns contain the KPIs and indicate the performance and resource consumption of the tasks. Measurements for times and durations are given in milliseconds (ms). Memory consumptions and data transfers are measured in kilobytes (KB).

The table of statistics records is displayed within an ALV grid control and inherits all functions of this SAP GUI tool: You can sort or filter records; rearrange, include, or exclude columns; calculate totals and subtotals; or export the entire list. You can also switch to another display layout or modify the currently used layout. To access these and other standard functions, expand the toolbar by clicking on the Show Standard ALV Functions button (the black triangle that points to the right).

The measurements most relevant for assessing performance and resource consumption are the task’s Response Time and Total Memory Consumption. The Response Time measurement starts on the application server instance when the request enters the dispatcher queue and ends when the response is returned. It does not include navigation or rendering times on the front end, or network times for data transfers between the front end and the back end. It is strictly server Response Time. (Exception: For SAP GUI transactions that use GUI controls, the RFC-based communication with them occurs in roundtrips. Their total time is measured as GUI Time and included in the Response Time. Parts of GUI Time may be contained in Roll Wait Time, the remainder will contribute to Processing Time.) The end-to-end response time experienced by your application’s users may be significantly longer than the server Response Time. The most important contributors to server Response Time are Processing Time (mostly the time it takes for the task’s ABAP statements to be handled in the work process) and DB Request Time (the time that elapses while database requests triggered by the application are processed). In most cases, Total Memory Consumption is identical to the Extended Memory Consumption, but Paging Memory or Heap Memory may also contribute to the total.

From this list of statistics records, using criteria appropriate to your investigation, you find and inspect statistics records for tasks that are too slow or require too many resources.

Since even the most basic statistics record contains too much data to include in a tabular display, STATS gives you access to all measurements—most notably the breakdowns of the total server Response Time and the DB Request Time, and the individual contributions to Total Memory Consumption—of a selected record by double-clicking any of its columns. This leads you to an itemized view of the record’s measurements in a pop-up window (Fig. 3).

Figure 3: Pop-up window with all available measurements for a statistics record, subdivided into semantic categories on separate tabs.

At the top, it identifies the statistics record via its header data. With the up and down triangles to the left of the header data you can navigate from record to record within this pop-up. The available technical data is grouped into categories, such as Time, DB, or Memory and Data. Use the tabs to switch between categories. Tabs for categories without data for the current statistics record are inactive and grayed out. Documentation is available by single-clicking the field name.

To assess the data captured in a statistics record, consider the purpose that the corresponding task serves.
OLTP (Online Transaction Processing) applications usually spend about 25% of their server Response Time as DB Request Time and the remainder as Processing Time on the application server. For tasks that invoke synchronous RFCs or communication with SAP GUI controls on the front end, associated Roll Wait Time may also contribute significantly to server Response Time. For OLTP applications, the expected end-to-end response time is about 1,000 ms and the typical order of magnitude for Total Memory Consumption is 10,000 KB. Records that show significant upward deviations may indicate a performance problem in your application. You should analyze them carefully and use dedicated analysis tools such as transactions ST05 (Performance Trace) or SAT (Runtime Analysis).
In comparison, OLAP (Online Analytical Processing) applications typically create more load on the database (absolute as well as relative) and may consume more memory on the application server. Users of OLAP applications may have slightly relaxed demands of their end-to-end response times.

Conclusions

You want to optimize the performance of your applications and you want to ensure their linear scalability. For this you need reliable data that indicates the software’s response times and resource consumption. For ABAP-based applications, this data is contained in the statistics records that the SAP kernel captures automatically for every task handled by a work process. Using this information, you can identify critical steps in an application, determine which component is the bottleneck, and define the best approach for optimization.

The Performance Monitor (transaction STATS) is a tool for selecting, displaying, and analyzing statistics records. It helps developers and operators find the best balance between fast response times, large data throughput, high concurrency, and low hardware cost. The tool is easy and convenient to use and comes with a feature-rich user interface framework so that you can focus on the data and its interpretation.

Outlook

As a developer, and in the interest of your application's users, you are primarily interested in short end-to-end response times, but STATS focusses very much on server Response Time. Especially for modern browser-based or mobile applications, front-end and network times dominate the total duration of many user interaction steps, but their contributions are not contained in the statistics records.

Additionally, one of your interactions with the application may trigger multiple HTTP round trips into the ABAP back end. All associated statistics records must be considered for a complete account of the resource consumption, but their attribution is not always straightforward.

To fill these gaps, SAP's UI frameworks (especially SAPUI5 underlying SAP Fiori applications) collect relevant data on the front end and subsequently send it in front-end statistics records to the ABAP back end. There these front-end statistics records can be combined with the corresponding main statistics records.

I will describe the front-end statistics records in a sequel to this blog post. I will also introduce and explain transaction STATS_FE as the tool to display and analyze them.

References

Parts of this blog post are taken from my SAPinsider article on transaction STATS:
Identifying Performance Problems in ABAP Applications

Details on the collection and interpretation of statistics records are explained in SAP Notes:
579462 - Runtime parameter of the statistics collection
8963 - Definition of SAP response time/processing time/CPU time
1063061 - Information about response time in STAD/ST03
364625 - Interpretation of response time in 4.6
552845 - FAQ: RFC Statistics in Transactions ST03/ST03N and STAD

STATS is the successor of transaction STAD. As both tools work with the very same statistics records, the following two blog posts are still relevant:
Statistical Records Part 1: Inside STAD
Statistical Records Part 2: RFC Statistics

[Sebastian_Gesiarz]

Thanks, this combined with STMC_UI5 helps a lot.

[ManfredMensch]

Hello Sebastian,

I am glad that you find this blog post helpful. You may also like my post on the related transaction STATS_FE.

Best regards,
Manfred.

P.S.: Let me know if you are missing capabilities in STATS or STATS_FE that would be helpful for your purposes.

[gopichand_munagala2]

Hi Manfred, thank you. Lot of good information.I would like to add some additional information(100 character) to STAD . I have attempted to use TH_SET_App_info which is meant for astat files. How do I display that information. Or any other tricks ? I have activated asact.   I want to use stat file technique instead of updating any tables due to performance reasons. 

[ManfredMensch]

Hello Gopichand,

I am glad that you find my blog post on transaction STATS helpful. As of now STATS cannot yet deal with application statistics records. To analyze them you still have to use transaction STAD.

Kind regards,
Manfred.

[Tunahan]

Hi Manfred,

Thank you for the great tools like STATS, STAD and their documentation.

I have questions about activity logs of a program calling another program and RFC calls.

I created a simple program PROG_A which submits(calls) PROG_B without AND RETURN addition. I see just PROG_B in STATS for this run. There is no information about initiator program, PROG_A in this case. Also I searched with TransId but no luck.

Is there a way to get detailed information in STATS about this SUBMIT -without AND RETURN- and their activity logs?

If I call PROG_B with AND RETURN addition I can see both of them at STATS output but I could not find a connection between them because they have different TransID values.

Can RootContextID value be used to relate STATS data of PROG_A and PROG_B?

Kind regards

[ManfredMensch]

Hello Tunahan,

I am wondering about the SAP_BASIS release of your system. In the STATS development system the behaviour is different than what you are observing.

Best regards,
Manfred.

[Tunahan]

Hello Manfred,

I tested this case in two systems:

1-SAP_BASIS 756 with SP level 0000

2-SAP_BASIS 740 with SP level 0011

Best regards

REPORT Z_TEST1.



DATA lv_i TYPE i.



WHILE lv_i < 20000.



  lv_i = lv_i + 1.



ENDWHILE.



WRITE 'submitting test2 program'.

SUBMIT z_test2 .



*********************

REPORT z_test2.



DATA lv_i TYPE i.



WHILE lv_i < 5000.



  lv_i = lv_i + 1.



ENDWHILE.



SKIP.



WRITE 'Program z_test2'.

[ManfredMensch]

Hi Tunahan,

I have internally reproduced your observation – both in the STATS DEV system with the most recent SAP_BASIS, and in a system with SAP_BASIS 740 SP30.

• The plain SUBMIT leads to only one statistics record associated with the called program.


• With SUBMIT … AND RETURN there are two statistics records.
  They have identical values for the Session ID and the EPP Root Context ID.
  Interestingly, their timestamps are out of order: The calling program has a later timestamp than the called program.

Apparently, the plain SUBMIT works somewhat like a non-RFC function call or a method invocation, which also cannot be resolved by the statistics. This is on purpose to keep the overhead for recording the statistics small.

The documentation for SUBMIT … AND RETURN (relevant parts copied below) explains the behavior.

Best regards,
Manfred.

The addition AND RETURN determines whether the calling program is ended or interrupted. It defines in which internal session the submitted program is executed, how the current SAP LUW is handled, and where the program execution continues after the program call is completed:

Without the addition AND RETURN, the calling program and its SAP LUW is ended. The content of the system field sy-calld is copied from the calling program to the submitted program. The internal session is handled in one of two ways:

If the calling program was started with SUBMIT, the internal session of the submitted program replaces the internal session of the calling program at the same position of the current call sequence.

If the calling program was started with CALL TRANSACTION or LEAVE TO TRANSACTION, the submitted program is started in a new internal session of the current call sequence while the internal session of the calling program is kept at its position of the call sequence.

When the submitted program is completed, processing continues in both cases behind the position from which the calling program was started. The internal session of the submitted program and the internal session of the calling program, which still exists in the second case, are deleted.

The addition AND RETURN interrupts the calling program. The submitted program is started in a new internal session of the current call sequence. The internal session of the calling program and the current SAP LUW are preserved. The submitted program runs in its own SAP LUW. Once the submitted program is finished, its internal session is deleted and program execution of the calling program is continued after the statement SUBMIT in its internal session.

[Tunahan]

Hi Manfred,

Thank you very much for the detailed explanation. It makes sense, now its clear for me.

Best regards