[ NOTE: If you are looking for information on Performance Tools and Tracing – this was covered in Part 1 of this series here ]
As a UX specialist in the SAP S/4HANA Regional Implementation Group, I’m privileged to work with many of our SAP S/4HANA customers. Many of these SAP S/4HANA customers are looking to leverage the business benefits of SAP S/4HANA by implementing SAP Fiori at scale. This means that you need to ensure that your SAP Fiori landscape is optimized for the best performance as this will help you both increase user adoption of SAP Fiori and realize real business benefits.
Good Business Outcomesdepend on business users using solutions easily, accurately & efficiently& a prerequisite for this is the OPTIMAL performance of SAP Fiori.
Performance refers to the total effectiveness of a computer system, including throughput, individual response time, and availability.
Factors in optimizing performance typically include:
Network bandwidth, pipeline, latency, HTTP compression, server and bootstrap (CDN) placement
Web Browser settings and Cache scheduling
Gateway and SAP Fiori launchpad configuration
Parallelization and co-deployment of OData services
CDS View optimization to support data volumes
Filtering and default values set for specific apps and Uis
Extension/Build approach for custom-built components
Patching of Kernel, Unified Rendering and SAPUI5 versions
Run an end-to-end Performance Trace before optimizing to identify the real bottleneck upfront and avoid wasted efforts
Monitor and tune for performance
”It’s no good tuning the engine if you have a flat tire”
Run a performance trace, identify where the bottlenecks are, then choose appropriate resolutions
This blog post is valid for all versions of SAP S/4HANA and SAP S/4HANA Cloud, private edition.
Disclaimer: This blog post is intended as general guidance only and you should check the embedded links to official SAP documentation which will be updated on a regular basis.
What we have already covered in Part 1 Tools and Tracing (link here)
Introduction to performance terminology
Performance tracing tools and techniques
HTTP tracing and performance decision guidelines
What we will cover in Part 2 Architecture & Other Considerations
Architecture considerations that could affect SAP Fiori Performance
SAPUI5 Development Guidelines
Content Delivery Networks
Links to the latest SAP Notes and Blogs for performance optimisation
Performance testing is an essential part of any SAP S/4HANA project – remember your SAP S/4HANA system is a business-critical system and changes to architecture & software layers need to be carefully considered and fully performance tested.
This is particularly true if you are re-platforming from an On-Premise environment to a Hyperscaler OR to an SAP S/4HANA Private Cloud Edition. While these target environments take care of many factors, there are always network, bandwidth, pipeline and general configuration settings (SAP Fiori Launchpad, App/UI configuration) & Custom Developments etc… that can have performance implications.
You need to consider General System Performance, example use cases that can have performance impacts include:
You are moving from a side-by-side solution to an embedded solution e.g.
CRM side-by-side to embedded CRM in SAP S/4HANA
BPC side-by-side to embedded BPC
SRM side-by-side to embedded SRM, etc...
Moving to an embedded solution changes how you are using your system.
Heavy data tasks that did not impact the main system performance when side-by-side, can impact system performance in embedded. This needs to be taken into consideration in sizing and architecture.
For example, if you are doing heavy pricing updates in CRM, you may need to configure additional app servers and adjust your load balancing to quarantine those updates.
You have users running very high-volume analytics in a side-by-side BW system that will now be run via embedded analytics.
Check the user behaviour of the people running these analytics and the after effects. Even when analytics are run in off-peak hours, depending on what analytics are run these can impact index behaviour for some considerable time (minutes to hours) afterwards. Consider whether the behaviour needs to change, or if you can execute these analytics in a more targeted way.
You are moving from local/frontend printing to remote printing
For high volume printing, moving to remote printing puts additional load on your system. You may also need to consider load balancing your print work processes. You should also review/load and architecture when using the ADS (Adobe Document Server) when generating PDFs
Patching and Support
One of the best things you can do to optimize performance is to make sure your support and patching is up to date. A lot of performance improvements are provided through patching, this is further detailed in the blog post below:
Furthermore, runtime performance is how your page performs when it is running, as opposed to loading. The Chrome Developer Performance Profiler tutorial teaches you how to use the Chrome Developer Tools Performance panel to analyse runtime performance. Also, check the following links:
The usage of a Content Delivery Network (CDN) for bootstrapping the SAPUI5 framework is desired as this is best practice for optimal performance in global enterprises. The fast cache of the Internet Communication Manager of an ABAP system can save processing time of a resource request if the resource was already cached. But for companies, which are spread across countries and continents, gaining faster loading times for initial requests from the server cache still could be insufficient. It would be better to provide caching hubs closer to the geographical zones of the users. Such network of cache servers is called a Content Delivery Network (CDN). The cache servers are prefilled with contents from the original web server.
The following links detail what is permitted and how to set up a CDN when it is supported by the architecture.