As a business application developer, you need to ensure that your apps run with optimal performance. While this holds for all types of applications, in this blog post I am specifically looking at web apps, and in particular I am focusing on SAP S/4HANA applications using web-based access.
Your app’s users demand short end-to-end response times to work efficiently. For each user interaction of your web application, you can break down its end-to-end response time into three main contributors:
- Front end (web browser or native mobile)
- Network
- Back end (for SAP S/4HANA web applications this is further subdivided into the ABAP business logic and the SAP HANA database persistency)
You need reliable measurements on these portions to assess a dialog step’s duration. (Some user interactions may be handled exclusively on the front end. These front-end-only steps do not have any contributions from network and back end.) Most user interactions in Online Transaction Processing (OLTP) applications have their end-to-end response times dominated by the front end plus the network contributions.
Another relevant aspect of your web application’s performance is its back-end resource consumption. Here the challenge is that one user interaction triggers an unpredictable number of HTTP roundtrips into the back end. They must be identified and aggregated to get dependable data on consumed hardware resources like CPU time or main memory.
In my previous blog post Measure your Application’s Performance and Resource Consumption: Evaluate Statistics Records with Transaction STATS I have described the statistics records collected by the ABAP kernel and I have explained how you use transaction STATS to display and interpret the relevant statistics records. I have also mentioned some limitations of the statistics records, especially that they focus on server response time and that they correspond to individual tasks executed in the ABAP back end.
In this blog post I explain how front-end statistics records fill these gaps and how my transaction STATS_FE gives you a complete end-to-end picture of the performance and scalability of your web application. You can use STATS_FE since SAP NetWeaver 7.56. I am continuously improving it and this blog post presents the tool’s state for SAP NetWeaver 7.57 as of late January 2022.
What are Front-End Statistics Records?
SAP’s most important UI frameworks (SAP GUI for HTML, SAPUI5, and Web Dynpro ABAP) have been equipped to take performance-related measurements on front-end devices. Client-specific performance information is collected per user interaction. Even some—but not all—of the previously mentioned front-end-only steps (user interactions without associated HTTP requests) trigger the logging of front-end statistics. At the end of a user interaction the gathered data is assembled into a front-end statistics records which will subsequently be sent into the ABAP back end.
The available meta data
- identify the application and the user interaction step,
- indicate the front end’s operating system, and the HTML browser with its version,
- specify the UI framework,
- establish the connection to the back-end statistics records that correspond to the HTTP requests.
(In my blog post on STATS, they were simply called statistics records. From now on I will use the more precise terms back-end or main statistics record.)
Time durations are available for
- end-to-end response time
difference between the start and end times of the user interaction as determined by the UI framework - client navigation time
sum of all HTTP request’s navigation times, corrected for overlaps - client round trip time
sum of all client-side HTTP request durations, corrected for overlaps - client processing time
calculated as end-to-end response time – client navigation time – client round trip time - back-end request time
sum of all client-side HTTP request durations, measured on the front end - server response time
sum of all server-side HTTP request durations, measured on the back end and sent to the front end with the HTTP response - network time
sum of all (client-side HTTP request durations – server-side HTTP request durations)
KPIs related to data transfer include
- number of HTTP requests
- amount of data sent
- amount of data received
- a flag to indicate whether HTTP requests were compressed
As I have stressed in my previous post 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.” This continues to hold, and you should take the same preparatory steps as mentioned there.
How Do You Analyze Front-End Statistics Records?
To view the front-end statistics records related to the execution of your web application you run SAP GUI transaction STATS_FE in the ABAP system that acts as the back end for your web application’s execution. On the start screen (Fig. 1) you specify criteria for the subset of front-end statistics records you want to analyze. The filter criteria are subdivided into four areas.
Figure 1: On the STATS_FE start screen, you define filter conditions for the subset of front-end statistics records you want to analyze, specify from where the records are retrieved, and select the layout of the data display.
You determine the Monitoring Interval in the topmost area. 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. You want STATS_FE to show as few unrelated records as possible. Therefore, you adjust this interval based on the start and end times of your application’s execution.
You define additional criteria that the records must meet in the Record Filter area. Be as specific and restrictive as possible, so that only records relevant for your investigation will be displayed. Particularly helpful are client and user. If you want to focus on expensive user interactions in your web application, you can specify lower thresholds for measurement data, such as end-to-end response time or number of network roundtrips. The other conditions support advanced analyses and comparisons.
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_FE. The option Include Statistics Records from Memory is selected by default, so that STATS_FE will also process records that have not yet been flushed from the memory buffer into the file system.
Under Display Layout, select how the associated subset of key performance indicators (KPIs)—the captured data—will be arranged in the tabular display of front-end statistics records. The pre-selected layout shows all KPIs from the front-end statistics records and the most important aggregated KPIs of the associated back-end statistics records.
What do You Learn from Front-End Statistics Records?
Fig. 2 shows the list of front-end statistics records based on the settings specified in the STATS_FE start screen (Fig. 1).
Figure 2: Front-end statistics records matching the criteria specified on the STATS_FE start screen (Fig. 1). The list shows front-end statistics records that correspond to the creation of a sales order with SAP S/4HANA application F3893.
The table displays the selected front-end 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 user interaction. The data columns contain the KPIs that indicate the performance of the user interactions. These columns are subdivided into two groups: Those with a gray background show the performance-related measurements taken on the front end. They are the true front-end statistics records. The columns with the yellow background cover the most important aggregated KPIs of the associated back-end statistics records.
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. To access them, expand the toolbar by clicking on the Show Standard ALV Functions button (the black triangle that points to the right).
The End-to-End Response Time is split into Client Navigation Time, Client Round Trip Time, and Client Processing Time. This breakdown tells you if a slow user interaction suffers from technical problems to start the first HTTP request, in which case Client Navigation Time would be high. A large Client Processing Time typically indicates that the interpretation or rendering of the HTTP requests takes too long. Slow HTTP requests show up as high Client Round Trip Time. This KPI takes into account if HTTP requests overlap. The related KPI Server Request Time does not apply such a correction, but simply adds the individual request’s durations. HTTP requests can be slow because their processing in the back end takes too much time, or because the network communication is too slow. This latter case is indicated by a high Total Network Time.
For most dialog steps in SAP S/4HANA applications, users expect an End-to-End Response Time below 1 s. To reliably achieve this, Client Navigation Time plus Client Processing Time shall be below 300 ms, and Total Network Time in a wide area network must not exceed 350 ms. The remaining 350 ms are available for back-end processing.
Further data, on the communication between front end and back end, are the Network Roundtrips, and the transferred amount of data, split into Sent Data and Received Data. The Compressed flag is blank if there is at least one uncompressed response body with size above 1 KB.
To achieve an End-to-End Response Time less than 1 s a user interaction must not trigger more than two non-overlapping synchronous roundtrips and ideally does not transfer more than 10 kB of data.
For each front-end statistics record, STATS_FE finds the associated main statistics records and aggregates their most important KPIs: Durations are summed; for memory consumptions, the maximum is determined. The values (together with the number of detected main records in column Count of Main Records) are displayed with a yellow background. With these measurements you can assess the user interaction’s overall resource consumption in the back end.
As a rule of thumb, a simple dialog step (expected End-to-End Response Time below 1 s) shall use less than 350 ms ABAP CPU Time and less than 150 ms HANA CPU Time.
You might expect that Network Roundtrips always equals Count of Main Records, but the front-end statistics may include requests that have been handled by the browser cache, or requests that were sent to other back ends than the one where you run STATS_FE, or requests that serve generic purposes not directly relevant to the application’s business objective. On the other hand, the back end may internally trigger tasks (e.g., RFCs, UPDATEs) resulting in separate main statistics records. Therefore, deviations in both directions are possible. Front-end statistics for which Network Roundtrips equals zero indicate front-end-only steps.
Based on this list of front-end statistics records you identify and focus on user interactions that do not meet expectations—either because they are too slow or because they require too many resources.
Figure 3: Main statistics records associated with the seventh front-end statistics record from Fig. 2.
Double-clicking an entry in the list of front-end statistics records takes you to transaction STATS and there displays the main statistics records associated with the user interaction (Fig. 3). You analyze this set of back-end statistics records as describe in my STATS blog post to understand the back end performance and resource consumption of all activities that were triggered by the user interaction represented by the chosen front-end statistics record and that were handled by the ABAP system where you currently work with transactions STATS_FE and STATS.
Conclusions
Front-end statistics records contain performance-related data for user interactions on front-end devices. They are collected by SAP’s most frequently used UI frameworks and then sent into the ABAP back end. There you can use the Front End Performance Monitor (transaction STATS_FE) to select, display, and analyze the front-end statistics records related to your application. As developer or operator, you use this tool to assess the contributions to the end-to-end response time of user interactions in web applications whose performance you want to ensure. The integration of the main statistics records and the coupling with transaction STATS enables the simultaneous evaluation of the resource consumption in the back end.
STATS_FE supports a holistic end-to-end view on the performance, resource consumption, and scalability of web applications. Starting with the set of front-end statistics records of a complete business process, you obtain the overall resource consumption, and you identify the critical user interactions. Focusing on them you understand which component (front end, network, or back end) is the bottle neck. If you conclude that this is the back end, a drill-down into the associated main statistics records will get you even closer to the root cause.
Disclaimer
The statistics records (front-end as well as back-end) constitute measurements and therefore can have neither absolute precision nor absolute accuracy. To improve reliability and confidence in the data, reduce the impact of variability with an increased sample size (i.e., take averages of multiple measurements), and detect conceivable bias by comparing with data from other tools.
References
You find an introduction to statistics records and transaction STATS in my recent blog post Measure your Application’s Performance and Resource Consumption: Evaluate Statistics Records with Transaction STATS.
I have published an SAPinsider article on transaction STATS:
Identifying Performance Problems in ABAP Applications
