Caching Use Cases

Why do we cache?

Rule 1: Personally Identifiable Information (PII) should never be cached! 

LAYERS
eCDN

Cloudflare only caches static content such as images, JS, CSS, etc.  The output of the CF-Cache-Status header shows
whether a resource is cached. The most relevant status are as following. 

HIT - The resource was found in the eCDN's cache.

MISS - The resource was not found in eCDN's cache and was served from the origin web server.
DYNAMIC - The resource content type was not cached by default and your current eCDN caching configuration doesn't
instruct the eCDN to cache the resource. Instead, the resource was requested from the origin web server.

HIT and MISS are used for static content like images, JS, CSS.
DYNAMIC is used for all non-static content like HTML.
Use Case Examples:
Issue: “I can’t see any changes when using Polish feature” or “Polish level feature broke image transparency”

● Check should be to see if the customer changed a Cloudflare setting?

● Can they turn it off and the issue goes away?
● If customer made a change to eCDN settings such as minification (for JS & CSS only), and polish (for images) the
changes may not reflect right away. So if an immediate change is needed a cache clear maybe required. However
a cache clear is discouraged as it can have negative performance impact.

Steps to Troubleshoot:

● Try to reproduce
● Isolate to just eCDN if stacked and if not hit Origin directly
● Use the Web Developer tool and check CF-Cache-Status header & other network details to see the exact URL,
status code, Ray-ID, dwsid, timestamp etc.
● Check Logs

Resolution Steps:

● Isolating the issue - What asset is being cached is it DYNAMIC or STATIC? as eCDN should not be caching any
dynamic pages such as HTML. Once to also validate the issue eCDN or not is to check the issue directly on origin.
Do the same exact steps on Origin by taking eCDN or any stacked CDN out of the picture.
● eCDN Cache Clear - This is an option that can take place once all others have been ruled out as clearing eCDN
cache is not the solution. Also this is not a cache clear option that is client facing. 
● To request eCDN Cache clear you need the zone name and open a user story to SRE team. 

NOTE: A cache clear on eCDN is discouraged as it can have negative performance impact.

References:
DOC - Clear eCDN cache
KBA - How to clear the eCDN cache
KBA - How does the eCDN provider cache data and why invalidating cache through BM doesn't work?
QUIP - Should I Purge eCDN Cache?

DIS

The Dynamic Imaging Service (DIS) is a platform feature that allows customers to upload a single HQ image to their
instance and then transform it via the feature’s functionality to different sizes that can be used for multiple purposes.
The flow can be seen below:
Each of this transformed images have a fingerprint and when there is an issue with the fingerprint, a DIS cache clear is
needed to get things working if there ends up being a fingerprint mismatch between the bytes on the POD instance.
One major cause is replication synchronization issues where the rendered site page has the new fingerprint but the new
bytes have not completed replicating to the instance. This causes a request with the new fingerprint would generate a
call to the POD that retrieves and associates the older bytes with a new fingerprint in the cache. 

NOTE: DIS cache clears are rarely needed post 19.10 as there was a change in that release in how the fingerprints are
calculated. Before they were calculated when the image content changed but now, they are calculated when the image
content and/or its metadata changes. This ensures that new fingerprints and images are generated when needed.

Other potential DISv2 issues that might occur:

-- Missing image(s) : Image is not loading on storefront sites.
-- Incorrect image(s) : The image showing in the storefront is not the same as the image(s) stored in DISv2 or origin.
-- Image(s) load slow : Image takes more than a couple of minutes to load in storefront.

Please follow troubleshooting steps in the INTERNAL CC: How does Support troubleshoot imaging issues with DISv2?
KBA in the references section.

Example of non-working and cache miss headers below

Working Header
References:
KBA - Cache Invalidation for DISv2 Request
KBA - INTERNAL CC: How does Support troubleshoot imaging issues with DISv2?
FAQ - Dynamic Imaging Service FAQ
FAQ - Dynamic Imaging Service Implementation Guide

Web tier / JWA

Static and Page Cache

These are the 2 main caches for different kinds of content which can each be configured and invalidated separately.
Even though these caches are set at the web tier, both are configured in BM under Administration > Sites > Manage
Sites.

● Static content cache: Images, icons, CSS style sheets, and other non-dynamic assets (set on a global basis)
● Page Cache: HTML pages generated from ISML templates when the <iscache> tag is used (set on a per site basis)
○ Page Cache Partitions: Allow you to group certain pipelines/controllers together which so that they can be
invalidated as needed without impacting the entire site’s performance.

In terms of replication, the cache that is invalidated is the page cache. Code replications invalidate the page cache
automatically while you have the option to invalidate the entire page cache in data replications if the cache
invalidation option is chosen. Page cache partitions can’t be invalidated as part of the replication process since that’s
triggered from Staging. If you plan to only invalidate certain page cache partitions, this must be done manually or via a
job in Production.
There are other rules that govern specific data that’s replicated in the Data Replication section of the Page Cache and
Replication information center topic.

Use Case Examples:

● Need promotional content available for start of a sale

● No getting consistent results on one or more specific pages

Resolution Steps:

● Identify what pipeline is used to populate the affected page e.g. Product-Show for PDPs, Search-Show for PLPs,
etc. 
● In a lower instance, determine what is cached on a page using the storefront toolkit.

References:
DOC - Static and Page Cache
DOC - Configure the Static Content Cache
DOC - Configure the Page Cache
DOC - Create a Page Cache Partition
DOC - Invalidate a Page Cache Partition
KBA - Improve caching and performance for high traffic events (such as big sales, flash event, and email blast) using
unique URL parameters

NOTE: By default, we cache pages that generate the following HTTP status codes: 200, 301, 302 and 410. Pages that
generate a 404 HTTP status are not cached by default but they can be if the the 404 Error Caching feature switch in BM
is enabled (Note: This is a customer visible feature switch).

Promotion / Pricing

● PLP 
● PDP
● SFRA - Usage of promotionCache

/*On PLP promotion prices are shown in SFRA using app_storefront_base/cartridge/models

and app_storefront_base/cartridge/models/product/productTile.js */

//line 43-
decorators.searchPrice(product, priceProductHit, promotionCache.promotions, getSearchH

 /* globals session */

'use strict';

var PromotionMgr = require('dw/campaign/PromotionMgr');

var collections = require('*/cartridge/scripts/util/collections');

var promotionCache = Object.create(null);

 Object.defineProperty(promotionCache, 'promotions', {
    get: function () {
        if (session.privacy.promoCache) {
            return JSON.parse(session.privacy.promoCache);
        }
        var activePromotions = PromotionMgr.activeCustomerPromotions.getProductPromoti
        var promoIds = collections.map(activePromotions, function (promo) {
            return promo.ID;
        });

        session.privacy.promoCache = JSON.stringify(promoIds);
        return promoIds;
    }
});

module.exports = promotionCache;

References:
GUS - W-7742735

Einstein

● Content Slots - Einstein (personalized) product recommendation content slots should not be cached.
● Predictive Sort -  PLP pages where predictive sort is used should not be cached, else it results in some issues like
duplicate products on the storefront pages.

SFRA Code : 

  if (!apiProductSearch.personalizedSort) {
            searchHelper.applyCache(res);
        }

Site Genesis:

<!-- Only cache product-grid content if it's not personalized -->

<iscache hour=“[duration]” varyby=“price_promotion" if=“${!searchModel.isPersonalizedS

Reference
KBA - Possible causes for products getting duplicated on search category pages

OCAPI

● Shop API 

{
  "_v" : "20.10",
  "clients":
  [
    {
       "client_id":"[your_own_client_id]",
      "resources":
      [
        {
          "resource_id":"/categories/*",
          "methods":["get"],
          "read_attributes":"(**)",
          "write_attributes":"(**)",
          "cache_time":900
        },
        {
          "resource_id":"/products/*",
          "methods":["get"],
          "read_attributes":"(**)",
          "write_attributes":"(**)",
          "cache_time":900
        },
        {
          "resource_id":"/products/*/availability",
          "methods":["get"],
          "read_attributes":"(**)",
          "write_attributes":"(**)",
          "cache_time":60
        },
        {
          "resource_id":"/products/*/prices",
          "methods":["get"],
          "read_attributes":"(**)",
          "write_attributes":"(**)",
          "cache_time":300
        },
        ...        
      ]
    }
  ]
}

Reference
DOC - OCAPI Caching

Database

ORM Cache
The ORM (Object-Relational Mapping) layer is used to translate the different data stored in our platform e.g. customers,
orders, inventory, site preferences, etc. back and forth from their actual states to the data in the database tables. In
order to do this at the speed our platform needs to operate, the ORM layer uses two caches:

● InstanceCache / unique instance cache: This cache keeps the transactional state and provides 'eventual' read
consistency for loaded ORM objects. As long as the data structure (think of this as metadata) is in use and
garbage collection has not cleared the data structure references from the cache, the data in this cache will
remain in place. It's not limited in size due to how much data it holds and it is up to the discretion of the JVM to
remove references not longer in use.
 ● SharedCache / least recently used (LRU) cache: This cache holds actual data from the database and is essentially
used to reduce the number of SELECTs to the database even when the data is not currently in use. This ensures
that the application servers do not need to query the database for certain data if requested. This structure is size
limited and newer entries will replace older once in a nearly least recently used fashion. This is a soft cache which
means that the JVM will clear it when there is a need for more memory.

The ORM caches play a role for the performance of an instance. As with all caches, the goal is to have a cache hit ratio
as high as possible to decrease the load against the database and therefore increase/maintain performance.

References
KBA - INTERNAL CC: ORM cache and hit ratio in general

Performance 

Per our sale KBAs, we recommend that key pipelines such as Search-Show, Product-Show, Home-Show and any others
that are critical to their site need to be performant i.e. <500 ms and at least 70% cache hit rate. CCAC/Reports &
Dashboards can be used to check this and the information below can be provided if they are looking for ways to
improve caching.

References
KBA - Caching Information and Problem Resolution
DOC - Page Caching in Templates
DOC - iscache Element