Skip to Content
Technical Articles

Evaluating Performance with SAP EarlyWatch Alert

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!

You must be Logged on to comment or reply to a post.
  • Hi Susanne,

    I did explore the features .Thanks for this article.

    As the EWA workspace derives the reference value  for average response time based on historical data , I suppose it added more difficulty answer the customer’s question – ‘What is a good performing system?’

    It was always difficult to convince many customers when we said an average dialog response < 1 sec is good one, but that’s what was SAP’s suggested value.

    What would you answer to a customer  about the performance of the system with this response time ?

    • Hi Sumit,

      the latest week shows a response time below 800 ms with an approximately even share of CPU and DB time, which looks good. Mid of April there was an increased CPU time and the "Others" share increased, too. You should drill-down into the hourly averages by clicking on the bar to see more details. And it always makes sense to check the transation profile which is also available in the SAP EarlyWatch Alert dashboard.

      Best regards,


      • Thank you, We are already working on the transactions contributing to high response times.

        The two things I'd wish to know:

        1.When we say 'average', it's  almost certain some of the response times will go beyond average value in that duration. What's the duration we should consider? Isn't it to be monthly as the customers talk about?

        2. You said 800 ms is a good one (in line with classical SAP's value of 1 sec),but customers argue 800 ms is a high value than they expect with an era of S/4Hana. It's become never-concurring thing to settle and say a particular value is threshold for good performance. Should we believe it to be 1 sec ?


        • Hi Sumit,

          1. The weekly average values are the standard. Talking to customers we always use this.
          2. As I said in the article, a fixed reference value is only a rule of thumb, you always have to look the the details and systems have very different mixtures of applications and cannot be compared.

          Best regards,