Title: SAP Commerce Performance | Commerce Cloud Integrations Source: https://www.commercecloudintegrations.com/performance Publisher: Commerce Cloud Integrations # Faster product pages, search, cart, and checkout Orders are lost in waits whose causes the shopper never sees: facets computed on every Solr query, OCC fan-out per product page, the same cart calculated twice. We trace one route from browser to database and remove each wait at its source, down to the cronjobs that compete with shoppers for the database. *Animation: Two browser windows side by side showing the CCI store. In the left window every page loads slowly and the shopper closes the window at checkout. In the right window every page loads at once and confetti falls on the confirmation. Under each window a bar shows time spent waiting and time spent shopping, and a list names what is slow on the left and what is fast on the right.* ## Where a slow page spends its time The patterns we fix most often, on four requests of a Composable Storefront shop, from the server render down to the database. Request Product pageCategory pageAdd to cartPlace order Before or after our changes BeforeAfter Before Response After 1. 2. 3. 4. 5. 6. 7. 8. 9. GET /cms/pages?pageType=ProductPage No Cache-Control header, so every request for the page layout reaches the platform. - Time we remove - After the change - Unchanged - Moved out of the wait ## Before Black Friday The date is known months ahead, and so are the ways a peak fails. We work through them on the calendar, from the day the date is set. 1. When the campaign calendar is set ### Baseline and capacity request We baseline normal traffic in Dynatrace and file the capacity request with SAP, backed by last year's curve. 2. Before the code freeze ### Load test of the event We load-test the event's own traffic shape on production-shaped data and fix what fails first. 3. At the code freeze ### The peak build The patch you load-tested, a kill switch on every third-party call, and only the promotions the campaign needs. 4. The week before ### Dry run The whole plan runs once against a load test, and every decision in it has an owner. 5. During the event ### Hands off the platform No deployments, ImpEx, full catalog syncs, or full indexing, and no ad-hoc queries in hAC or Backoffice. 6. The week after ### Written down Curves, incidents, and near misses go into next year's plan within the week. ### Every active trigger, by its next run Every job that lands in trading hours gets a named owner who agrees it stays. Full syncs, exports, and feeds move to the quiet hours. hAC, FlexibleSearch ``` SELECT {cj:code}, {t:cronExpression}, {t:activationTime}FROM {Trigger AS t JOIN CronJob AS cj ON {t:cronJob} = {cj:pk}}WHERE {t:active} = 1ORDER BY {t:activationTime} ``` ## Fixed-scope engagements - ### [Route performance audit](https://www.commercecloudintegrations.com/composable-storefront#/p/route) An end-to-end trace of one to three routes, from the browser through SSR, OCC, Solr, and the database. You get the time spent per layer and a backlog ranked by measured gain. - Trace per route with time spent per layer - Ranked backlog with expected gain per item - Release gate with the route budget 4 to 6engineer-days - ### [OCC performance pass](https://www.commercecloudintegrations.com/composable-storefront#/p/perf) Removal of the request waterfall between the storefront and OCC. We trace what each route loads, batch entries, stock, and price into one call, add cache headers, and prefetch per route. Before and after timings are part of the delivery. - Waterfall diagram per route, before and after - Batched OCC endpoints with field sets - Cache headers and CDN rules 5 to 8engineer-days - ### [Solr and database tuning](https://www.commercecloudintegrations.com/composable-storefront#/p/solr) Tuning of the Solr schema, boosts, facets, and indexing, plus slow queries and missing indexes on the database. Every change ships with the before and after measurement that justifies it. - Solr schema and query changes with measurements - Index and query fixes on the database - Indexing schedule that does not compete with traffic 5 to 8engineer-days ## Questions before a performance review Where do you start on a slow site? With the slowest request that carries revenue. We rank requests in Dynatrace by response time and traffic, then trace the worst one from the browser to the database. Tuning starts when the trace names the layer. [Dynatrace on SAP Commerce Cloud](https://www.commercecloudintegrations.com/guides/dynatrace-observability-on-ccv2) Will more pods fix it? Only when the trace says the pods are the constraint. Doubling the storefront nodes does not double throughput when the database, Solr, or an external service is where the request waits. [Performance engineering for SAP Commerce](https://www.commercecloudintegrations.com/guides/performance-engineering-for-sap-commerce) How do you prove a change worked? One change per load-test run, against the same journeys and the same data. A change that does not move the 95th percentile of its request is reverted, not kept. [Performance engineering for SAP Commerce](https://www.commercecloudintegrations.com/guides/performance-engineering-for-sap-commerce) What access do you need? Cloud Portal access to your environments is enough for the first trace: Dynatrace and the Kibana logs open from there, and Dynatrace is part of the Commerce Cloud service. Changes go through your repository and your pipeline like any other release. [Dynatrace on SAP Commerce Cloud](https://www.commercecloudintegrations.com/guides/dynatrace-observability-on-ccv2) How does it stay fast after you leave? A scripted load test runs against the performance environment on every release, and a response-time budget per page type fails the release that breaks it. A slowdown is caught while the change that caused it is still the newest one. [Performance engineering for SAP Commerce](https://www.commercecloudintegrations.com/guides/performance-engineering-for-sap-commerce) When should we start preparing for Black Friday? When the date is fixed. SAP needs weeks of notice for extra capacity, and the load test has to find problems while there is still time to fix them before the code freeze. [Preparing for high-traffic events](https://www.commercecloudintegrations.com/guides/preparing-for-high-traffic-events)