Skip to main content

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.

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
Before or after our changes

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

    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

    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

    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
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
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
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
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
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