How long do you accept to wait for a screen refresh after you clicked a button or pressed ENTER until you get the feeling that either your WiFi has troubles or the app you are using is not so brilliant performance-wise?
For SAP Fiori a rule of thumb is that the user accepts one second for a standard app and three seconds for a complex one. This one-second-rule was used long before SAP Fiori for classical GUI transaction response time, because it fits to the human expectation. In the classical SAP EarlyWatch Alert service a threshold of 1.2 sec is used to determine a warning for the average hourly dialog response time of a SAP Netweaver system. But is this simple rule really sufficient to judge the performance of a system?
I would clearly say it is not. Today we have much better means to analyze the performance because we can rely on more data. Every system has its individual application fingerprint: the mixture of transactions is individual, the data footprint is different and the customizing of transactions varies. Therefore systems cannot be compared to one another and shouldn’t be judged with a unified threshold.
It is much better to check for end-user complaints and observe a system over time. To do so, start the dashboard in the SAP EarlyWatch Alert Workspace by clicking a system in the Top Systems card, and open the detail view for response time and activity.
Picture 1
The chart shows the weekly average response time for one task type and one system over time. The service automatically calculates a long-term average value, indicated as a dotted black line. The purple line shows the activity in steps. We can see an increasing trend in the response time independent of the number of steps. In this example the CPU time is increasing and should be investigated in detail.
As you can see the SAP EarlyWatch Alert Workspace is no longer using the fixed threshold of 1.2 sec, but works with individual reference values derived from the historical data for a system. The deviation from this reference is displayed on a card in Workspace. Here no absolute values of response times are compared between systems, but the change of response time is the criteria for a top list of systems:
Picture 2
This card displays up to 10 systems with the largest response time deviation of the current week compared to the long-run average of the system.
The displayed values are based on the most relevant task type of the respective systems – which is the task type with the maximum value of the product “number of steps” times “average response time” representing the maximum load.
Choose a system by clicking on the bar to display the temporal development of the response times in the different task types, as shown in Picture 1.
All charts in SAP EarlyWatch Alert Workspace are interactive: You can drill down into details. When you drill down in picture 1 by clicking on a specific week, you will come to the hourly average response times.
Picture 3
This helps you to identify outliers in the performance. In picture 3 you can compare two weeks, each from Monday until Friday. The lower chart shows an increased response time during the night time 01-04 am on Monday with a high share of database time. The purple line shows the typical daily pattern of activity in this system. The long response time occurred outside of the peak business hours.
You should watch out for outliers in response time that come along with a drop in activity compared to the usual pattern: this could be a system hang situation where many users are affected and can feel a bad response time.
The system specific dashboard in the SAP EarlyWatch Alert Workspace provides also an overview of the GUI transaction performance and OData request performance. With the help of this data you can identify individual specific performance issues.
The latest feature of the SAP EarlyWatch Alert Workspace released end of May 2020, is a statistics on long running ODdata requests used in UI5 applications, like SAP Fiori. This can be found in the new section User Experience in the dashboard.
Picture 4
You can find the top 5 OData requests by average response time in the dashboard and compare them with the reference value I mentioned in the beginning: one second for standard and three seconds for complex OData requests. The chart icon on the upper right corner will be available soon, and gets you to the detailed list of OData services, where you will get more details, like entity set and operation, which you will need in the discussions with your backend developers.
You can also switch from average call time to total call time to get an idea about the total load of this OData service. This helps you prioritize your optimization potential.
Let me know your thoughts on this by leaving a comment!