- SAP Managed Tags:
Unlike Page rendering in legacy Accelerator-based Storefronts running in Tomcat, Server Side Rendering of Pages (short SSR) runs in node.js which is single Threaded and can quickly become a bottleneck as traffic grows. This is the main reason why the Composable Storefront recommended Architecture requires a CDN:
Source: Recommended Setup for Server-Side Rendering
Performance Factors
There are three areas influencing SSR Performance that you can control to varying degrees, Application, Traffic and Resources.
Application
The complexity of your page plays a huge role in the time that it takes to render it. You should only render non-personalised data on the server, and carefully decide which components will be rendered in the Client and Server. You can also control call timeouts to external services to avoid holding on to resources, as well as reducing the number and response times of your API backend calls
Traffic
You can manage the amount of Traffic that hits the SSR nodes by controlling CDN Caching settings of your pages. Most CDN providers offer a cockpit where you can see the cache hit/miss ratio as well as detailed statistics. Recommendations vary depending on your actual use case, but some common settings are 1 Day of caching for Product Pages, and upwards of a 90% Hit/Miss Ratio.
Resources
Finally, there is always the possibility of increasing the number of resources to handle more traffic. Some resources, such as API are auto-scaled, others can be scaled by Request when high traffic is expected.
Be aware that the use of additional hardware is not a scalable strategy when there are deep underlying performance issues.
Who are your clients?
Another factor to discuss before you continue your performance journey is to analyse who really are your page visitors. Most pages have a mixture of Bots/Crawlers and Humans, and they have different requirements and tolerances. Whereas Bots can usually wait, human users want fast responses, so it's important that you understand how CSR timeouts and fallbacks work.
The default behaviour of the SSR Optimization engine is to fallback to Client Side Rendering (CSR) after the timeout provided in the configuration options has elapsed.
Ideally you want to identify your client and then handle rendering accordingly, for example you might implement a renderingStrategyResolver that examines the Agent header and always performs SSR for Bots and applies the Default strategy (or Always CSR) for Humans.
See Configuring the SSR Optimization Engine and Composable Storefront - SSR performance and timeout troubleshooting for further details.
Performance Testing
Armed with this framework, what concrete steps are to follow if you want to avoid performance issues or to improve response times of your current application?
The first step is to measure the performance of your current Application, following the guidelines given in Managing Performance in an SAP Commerce Cloud Project, focusing on 3 scenarios:
| Scenario | Description |
| DEFAULT | Running against the current configuration, using the default fallback to CSR after a timeout. |
| CSR | Attempting to immediately switch to CSR for all non-crawler requests |
| SSR | Forcing SSR for all requests using a crawler client header. |
Then measure response times across the different layers (Apache, JSApp and API nodes) using Dynatrace, this will help you identify bottlenecks. Perform an iterative process to identify and resolve Issues.
Additionally, consider the following points before starting with load testing, as these will save you a lot of time and effort:
- Make sure that you are running the latest version of Composable Storefront. Latest versions incorporate performance improvements that are difficult to retrofit to previous, and specially older, versions.
- Ensure that no Javascript errors are Present in the SSR Logs. Not only do these errors pollute the logs, they will either reflect additional issues or complicate troubleshooting.
- Verify that no memory leaks are present in your frontend nodes using Dynatrace and Cloud Logging. Check for Out of Memory errors in the logs and monitor memory variance. Beware of creeping memory usage followed by a node restart.
This graph demonstrates change in memory variance after a memory leak was resolved.
- Investigate rate limiting on the CDN. Sometimes the CDN can impose limits on calls to and from your jsapps node server, this is important to check.
- Apply the CDN recommendations listed in SAP Commerce Cloud, composable storefront CDN Caching Recommendations
- Enable the CMS Cache as described in Improve Spartacus and OCC performance with CMS Rendering Cache
- Review and apply Lighthouse Recommendations provided by Chrome Developer Tools.
Conclusion
The performance of SSR Applications requires a holistic view and careful tuning and so that components located outside SAP Commerce Cloud are also taken into consideration. Load testing plays a key part in managing performance, and trade offs might be required in order to use the available resources optimally.
