Caching in Salesforce Commerce Cloud — Part 2

In Part 1, we covered caching fundamentals and specific caching strategies for Salesforce Commerce Cloud. In Part 2, we cover techniques to optimize, measure, and report on the performance of your caching strategy.

Performance insights and optimization

Almost every website includes certain key pages that consumers typically spend the most time on. Those pages translate into controller or pipeline endpoints that should be monitored closely.

Key pages

Examples of key pages include:

• Homepage — Default-Start and Home-Show
• Product listing pages (search and category navigation) — Search-Show
• Product detail pages (PDP) — Product-Show
• Content pages — Page-Show

All such pages should have a high cache hit rate and fast response times. It is not easy to quantify high and fast as many factors come into play and good numbers do not necessarily translate into great consumer experiences.

Example scenario
Consider an implementation that generates links to variants on listing pages while the PDP will always redirect to the master product as a best practice. This will likely lead to fast PDP metrics as each call will effectively be two requests, one to a variant that will respond with a fast redirect and the actual PDP page. As a result the reported PDP average response time will be skewed and appear twice as fast as it actually is (assuming the redirect response time is close to zero). The actual customer experience will be poor, however, because not only is the PDP slow, but there is an additional redirect that makes it even worse.

Because a wide variety of situations can affect average response times, it is important to holistically look at performance and not focus on a single number as an indicator.

You can use the “percentage of processing time” metric from technical analytics reports in Business Manager as a good indicator for identifying the biggest optimization potential. To optimize you can either improve page caching or optimize processing times (via other forms of caching or code optimizations).

Common pitfalls
One common pitfall is missing cache directives that have either been removed from the code by developers or were not added when new endpoints were created. This can be easily spotted by using Reports & Dashboards and identifying endpoints that have a 100% cache miss rate (see the Tooling section below for more details).

As a best-practice all endpoints should be reviewed a few days after site launch to make sure that all endpoints that are supposed to be cached actually are.

Key includes

The following three calls should have a very high cache hit rate and fast response times. These are part of search and browse flows, which are the initial part of the customer traffic funnel.

• Product Tile — Product-Tile (this may vary)
• Content snippets — Page-Include
• Content Slots — __Slot-Render

Product search hit tiles should ideally have a 99+% cache hit rate and a response time <=1ms. This may sound high at first but in practice it is actually quite achievable due to the number of requests to product tiles. Experience has shown that a drop by only a few percentage points will lead to slow search result pages and reduced scalability.

Page Designer

When PageMgr.renderPage() renders a Page Designer page, the rendering process uses two nested remote includes:

• The first-level remote include is the system controller __SYSTEM__Page-Include. This remote include determines a visibility fingerprint of the page and its components based on schedules, customer groups, or other visibility settings. This remote include passes the visibility fingerprint to the second-level remote include.
• The second-level remote include is the system controller __SYSTEM__Page-Render. This remote include invokes therender function to render the page.

Each variation of the page based on different visibility settings is cached separately.

See the documentation for additional details.

Content slots

Content slots are served within remote includes to enable independent cache control. This lets you use cache directives in the rendering template that will control the caching for the slot content.

The system will automatically recalculate which slot configuration to show regardless of the cache settings in the rendering template through an additional dynamic include.

Cache optimizations and measurement

Cache efficiency is measured in terms of the cache hit ratio. Let’s understand these parameters before exploring tooling.

• Cache hits: Cache hit is a numerical unit to measure how efficiently cache is implemented and performing. This unit is measured based on “How many requests are served by cache vs redirected to the application server for processing”. Higher cache hits reflect efficient cache implementation.
• Cache misses: Cache misses is technically the reverse of cache hits. This is again a numerical unit of measuring how many requests were not served by cache and eventually ended up at application server for processing. Cache miss is good indicator to identify cache optimization potential. Cache misses can stem from many factors, including inefficient implementation, cache overflow, and dynamic URL parameters.
• Cache store: For fast access, cached data gets stored in high speed, key-value pair storage known as the cache store. The primary responsibility of the cache store is to deliver cached data based on a provided cache key, which can any unique artifact, such as a unique URL.

Tooling

When you’re looking to optimize server-side performance (and thereby increases the scalability and predictability of your system), the Technical tab of the Reports & Dashboards tool is a good starting point.

To identify the top contributors to your total processing time, sort by that column. Now you can see the endpoints that contribute most to overall processing time and thus hold the biggest potential for improvement.

After you’ve sorted, take a look at the last three columns; they indicate how many requests have been read from cache, calculated and stored to cache, and always dynamically calculated, respectively. When the last column shows 100%, the endpoint is uncached. This should be the first place you check, as there may be endpoints that are not cached but should be. Those are also the easiest to fix.

Next, validate the pages that are cached. If the last column is not 0%, then there are requests that are not getting cached, which could indicate errors or code issues. A page that should be cached would have 0% in this column and only have either cache hits or misses that then get stored to cache.

The next step is to review the cache hit rates and see if there is room for improvement, the previous sections explain how the page cache works and provide some ideas for possible optimizations.

Finally, once page caching is exhausted, you can focus on the (now updated) overall processing time again and take a closer look at the code to see how it can be optimized. For this step you might want to delve into the detailed report, which you can access by clicking the endpoint.

Once you feel page that your caching is working well and cannot be optimized further, you can use the
Code Profiler to gain further insights. In the tool, follow these steps:

1. Select Extended Script Development Mode
2. Filter by Category equals REQUEST
3. Sort by Elapsed time > Sum

The results will show the most calculation-heavy requests on top. You can click them to see which functions contributed to the run time. With production data you will usually find a short list of endpoints that contribute most to the overall processing time. The detailed report can then be sorted by Elapsed Time Own > Sum to identify the scripts and methods that are contributing most to the total. Start at the top and look into how to make those methods more efficient (see previous sections for guidance).

Be sure to read about Caching in Salesforce Commerce Cloud in part one of this two part series.

About the authors

Danny Gehl is a Success Architect at Salesforce. Danny has been working in the digital space for the last 16+ years and is one of the most experienced architects in this space at Salesforce. Danny is well known in the Salesforce Commerce Cloud customer and partner community, has been supporting the Commerce Cloud community since 2008, and has delivered some of the largest implementations of Salesforce Commerce Cloud.

Neeraj Yadav is a Success Architect at Salesforce. Neeraj has spent most of his career delivering digital transformation programs around the world. Neeraj joined Salesforce Commerce Cloud (previously Demandware) in 2015 after spending 12 years in product development and digital platform delivery. Neeraj’s areas of interest include system integration and product development.