Prepare Your SAP Commerce Cloud Solution for High Traffic
10 min read
Managing Performance in an SAP Commerce Cloud Project you learned about how to design and test your SAP Commerce Cloud solution for various types of performance scenarios. In this article you will learn how to prepare your solution for peak events, including tips and tricks for common areas we see that affect performance.
Table of Contents
It’s never too early to start thinking about how your SAP Commerce Cloud
solution will operate during the periods of heavy traffic. Below are the leading recommendations for
preparing your system for peak events.
To start you need to understand what would be your goals during those special event when traffic on you store increases. Common questions you can ask as part of your preparation include:
- Is traffic/sales data available from prior years of high traffic events?
- What are the business expectations for this year?
- What are minimum/shoot-the-moon sales goals?
- Are special promotions planned? How will they be marketed?
- Will you be running a flash sale (high volume in a short period of time) or prolonged sale (e.g. week-long sale)?
- What are your normal load distributions?
Develop, document and communicate traffic baseline thresholds and status using the pre-configured or your own custom dashboard in Dynatrace. Understand when the site is actually handling extraordinary load. This is important to provide feedback on marketing for promotional campaigns and to determine if there are problems which may be limiting traffic.
- How does the site perform under normal loads?
Develop and document baseline thresholds and status with dashboards in Dynatrace. Understand the best and worst case performance of the site under normal load. What are the fastest, slowest performing pages? What range of throughput for those pages/elements of the site is normal. This is important to understand the proper level of vigilance and decision criteria for planned or emergency corrective actions like adding/shifting capacity or throttling traffic.
- What are extraordinary loads like?
Develop and document a profile of extraordinary traffic characteristics from prior years and/or load testing. What kind of traffic/business volumes are expected hour by hour and timezone by timezone? What exactly are the extra preparations supposed to accommodate?
- How does this extrapolate to levels anticipated by business and marketing?
Develop and document a list of operational and reputational risk management guidelines based on your business priorities to inform all key players' emergency decision making during extraordinary business events. Use the context of expected load/performance to collaborate with business and marketing stakeholders. Help manage expectations. Enable planning and coordination of marketing activities driving traffic and resource planning around transaction volumes. Document the business goals, and make these available to operations teams to inform business-aligned operational decisions if emergency tradeoffs must be decided.
What are the likely (usual) suspects for performance or availability incidents?
Develop and document a profile of site technology hot spots and potential leading indicators of trouble, and provide status communication templates for incident management. Example hot spots:
- symptoms and indications of trouble, failure modes
- infrastructure bottlenecks
features or external services with bad performance characteristics
Opportunities and Limitations
Identify areas which can be changed to help the site approach or exceed the business goals. If demand
exceeds capacity, does it make better business sense to allow the whole site performance to degrade somewhat
in order to maximize sales, or does it make more sense to implement something like a queue to limit the
traffic to maintain performance within known limits, or is there another compromise that could
- Implement proactive infrastructure and configuration improvements
When you're aware of an upcoming high traffic event, you should notify SAP Support via a ticket as soon as possible. Even if the infrastructure can scale, it is not instantaneous and even a few minutes of your site being down can result in lost sales. By notifying SAP in advance the infrastructure can be proactively scaled and additional monitoring may be put in place
- Implement proactive infrastructure and configuration improvements
Collect review and implement all material performance recommendations from prior recommendations. Audit infrastructure and configuration for consistency, plan and make corrections. Run tests early to determine if additional infrastructure is required. Fix old problems and implement recommendations which might become performance risk factors during periods of high business volume.
Some of the opportunities may require much advance preparation, and some will require very little. Prioritize the work, and set expectations based on the level of success at each priority. Try to document the changes even if they will not be implemented prior to the high traffic event. If necessary these procedures will come in handy if emergencies require/justify implementation through incident management.
Special Event Release
It may be necessary or desirable to produce a special build/version of the site for high traffic event. For sites with poor performance characteristics under extreme load, this may be the only real choice. If you normally make use of expensive features, fork your production custom code base, and produce a "special event" build with expensive features disabled or minimized and configurable behaviors tweaked for high performance under high load. This build should be thoroughly tested in your lower environments and put into production well in advance of your high traffic period.
Special Event Operations
Identify software, infrastructure, management, and marketing resources to participate in on-call coverage and status checkpoint meetings. Identify resources to cover all points of infrastructure and technologies. This should include marketing operations if there is an operation to drive traffic using email or social media promotion. Circulate escalation procedures with contact information for all support and management (decision maker) resources.
Schedule hours of coverage around peak storefront business time and after hours back-office processes. Develop and provide communication templates for regular and emergency status reports, and distribution lists for those communications.
Special Event Performance Testing
The more preparation is necessary, the more it is necessary to test the process and special technology and infrastructure. Plan and conduct testing in lieu of prior years experience to cover any changes to the technology stack, staff, or support processes. As an organization gains experience, the testing can be scaled back to cover significant improvements to the current stack/staff/process. In lieu of prior years' experience, consider performing "shakedown" or "dry-run" of the whole production event preparation during the day, with load testing on a preprod environment.
- Make sure you are on the latest patch for the version of Core Commerce you're using. Often patches include fixes for bugs that could impact performance
- Freeze code changes far enough in advance to allow time for testing and implementation of unplanned bug fixes.
- Validate your environments' performance through stress and load tests.
- Consider implementing a content delivery network (CDN) or look at caching at lower levels. You can look at caching your CMS components or could look at solutions offered by SAP CX Services - check out our Portfolio of Services.
- For Commerce Cloud in the Public Cloud you may offload static media and ui requests to be served by the Apache Web server. It can be explicitly enabled on an endpoint in Cloud Portal by clicking on a slide box and adding the urls as per below (Storefront endpoint configuration):
- Review 3rd party performance, scale network bandwidth/server-side infra, etc accordingly, or disable unnecessary 3rd party calls during peak events.
- Confirm your Solr search configuration is optimized. See articles on Understanding Solr Queries and Solr Indexing for more information on how to tune your search queries and indexing processes.
- Review your cronjobs configurations--avoid having any non-critical jobs running during peak hours.
- Avoid running complex queries or reporting from back-office during business hours. This activity should be scheduled to run during off hours – possibly via cron jobs.
- Avoid running impex jobs during business hours and during major sale campaigns.
- Stock updates and pricing updates are expensive and need to be minimized as much as possible during peak sale hours.
- Review and disable all other updates or impexes related to operational data fetch that are not directly impacting immediate business decisions.
- Clean up large tables which are frequently accessed – pricerow, stock, products, cart, cart entries, task etc. As a housekeeping best practice these database tables need to be cleaned up/purged regularly via cron jobs scheduled to run during off business hours. See more tips in Data Maintenance and Cleanup
- Avoid updates of keywords/synonyms or Schema.xml files. This may have impact on search logic.
- Set up alerts in Kibana and monitor for exceptions related to data, custom logics, promotions etc. Prior to code freeze you should be working to fix these exceptions. This will help minimize chances of long garbage collection and memory saturation.
- Restrict the number of users with admin access to back-office and Cloud Portal to prevent any accidental catastrophic changes being made to your environment.
- Limit the number of banners, carousels and images in the homepage. Limit the number of products used in these carousel components.
- Review and reduce the sizes of images used – especially in homepage and product pages. This will have huge impact on page load times.
- Use caution with the number of active promotions at any point of time – advisable to have focused promotions for specific periods and disabling/removing unused promotions.
If you're managing your own on-premise instance of SAP Core Commerce you may also want to review the items covered in Infrastructure Considerations for On-Prem SAP Commerce.