Use Transaction STATS_FE to Analyze the Performance of your Web Application
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)
- 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.
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).
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.
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.
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.
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.
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
thank you for the new transaction & this blog.
How do I get as a customer SAP NetWeaver 7.57?
what I am (still) referring to as SAP NetWeaver is now called the ABAP Platform. NetWeaver 7.56 is ABAP Platform 2021, and SAP NetWeaver 7.57 will be ABAP Platform 2022. These platforms are used by the corresponding SAP S/4HANA on-premise editions.
A compact overview of these and other relations is in the blog post ABAP Platform Releases and Consumers.
Great blog, give us an overview of how you can retrieve key performance information from each tier of our application such as front-end, network, and back-end.
Hi Manfred, sorry this was not clear to me. Does this work when using Fiori front-end?
STATS_FE (and STATS as well) is an SAP GUI transaction. You run it either in your locally installed SAP GUI client software or in a web browser via SAP GUI for HTML. It is not a Fiori application.
Sorry Manfred, I didn't ask my question correctly. When Fiori is used for say reporting or maybe a Fiori app will this tcode/app capture the front-end Fiori activity.
if the application you are interested in uses one of the supporting UI frameworks (SAP GUI for HTML, SAPUI5, and Web Dynpro ABAP) the involved framework will collect the front-end statistics and send them into the back end. Then the answer to your question is yes.
Does STATS_FE support Transactional apps?
Also I don't see the statistics for Custom UI5 apps in STATS_FE. Can you please let me know if you've any idea on this.
Thanks and Regards,
I am glad that this blog post is meaningful for you.
STATS_FE is a display tool for statistics records recorded previously and autonomously (you do not have to explicitly activate the logging). Therefore it works for all types of applications that are capable of collecting front-end statistics and sending them into an ABAP back end. In particular, it works for applications that use the frameworks for SAP GUI for HTML, SAPUI5, or Web Dynpro ABAP. Whether it is a transactional or an analytical app is—in this context—of no relevance at all.
Hi Manfred, this is a great post. I'm using STATS_FE for our Fiori system with I believe is written in SAPUI5. I do no see any info in STATS_FE. I do see lots of good information in STATS. Is there something our Basis team has to config to get the front-end stats pushed back into the ABAP Layer?
do you have a standalone SAP Gateway instance? Then the frontend sends its requests and therefore also the front end statistics records there and you need to run transaction STATS_FE on this instance.
Hi Manfred, I had to ask my Basis team about the standalone Gateway. They told me "it is a Gateway integrated into ASCS instance" and "We cannot directly logon to ASCS". Does that help with understanding why the Front-end statistics do not appear to be getting to the backend server?
unfortunately, the term gateway is used for two different concepts:
(Both descriptions are copied from corresponding entries in help.sap.com).
In the context of front end statistics records, the second concept is relevant. Your basis team was most likely thinking of the first concept.
The deployment options for the SAP Gateway Foundation are described here. I think that you have a central hub deployment.
Thanks Manfred, my basis person told me for us it is inbuilt with Fiori. Not sure if that helps with this discussion. One other point is we are at 7.56 patch 00. Any chance this may not be working due to our release level? I know your blog references a more current release.
transaction STATS_FE is available from SAP_BASIS 7.56 onward.
Dear users of STATS_FE,
please be informed that you may have to install SAP note 3168075 "STATS_FE: Correct Time Zone Handling" into your system for STATS_FE to work correctly for all time zone settings.
thanks for the description of the interesting new feature.
We just tried it with a Floorplan Manager Z application.
We found that the "FE processing time" in our case included the time where the front end waits for the user to click a button. The processing step consisted of 2 roundtrips.
Is this supposed to be like that? Or is this due to "incorrect" GUI programming on our side?
the main idea of the front-end statistics records is to measure one user interaction. The key metrics are end-to-end response time, client navigation time, and client round trip time; from which client processing time is calculated as end-to-end response time – client navigation time – client round trip time. A user interaction on the front end may trigger multiple requests into the back end. But it is always one single interaction, and not waiting for yet another button click. Therefore the answer to your question "Is this supposed to be like that?" is a clear No.
on which component should we open a ticket (if we have the time)? Performance Tools? FPM?
I am convinced that STATS and STATS_FE display the information they receive from the kernel via the statistics files without changes that go beyond formatting. Therefore the performance tools component will not be helpful. The FPM component sounds more reasonable. But I admit that I am not a frontend developer.
it would be helpful to find out which frontend framework is used:
SAP GUI for HTML, WebDynpro, ...
Then a message can be opened on the related component which contains a step by step description how to reproduce the issue.
468951 / 2022