Page Cache and Replication in B2C Commerce

Cache Clearing Behavior

When data or code replication runs, a site cache invalidation automatically starts. When you initiate a cache invalidation manually, the system begins a process of invalidating cached data. To reduce impact to performance and to minimize potential disruptions, cache eviction completes over a period of 15 minutes (referred to here as the "Clear Period").

Important Repeatedly triggering cache invalidation within this "Clear Period" interferes with complete eviction of the cache. Frequent invalidation requests do not speed up the eviction as expected but can actually prevent it from invalidating in entirety. Despite multiple attempts to clear the cache, the site can retain outdated data since each clearing attempt resets the "Clear Period".

Types of cache invalidation that use this process:

• Cache invalidation (Entire Site and / or Partition) via Business Manager | App Launcher | Administration | Sites | Manage Sites | Cache
• Jobs that trigger a Page Cache Invalidation

Best Practices

• Only perform cache invalidation when necessary.
• After initiating a cache invalidation request, allow the "Clear Period" to elapse for the system to complete the eviction process.
• For use cases which require frequent updates to the site, for example: frequent price changes, consider using Granular Replications instead of data replication to avoid waiting for the "Clear Period" and for the site to be updated.
• If you're performing frequent cache invalidation due to stale data, investigate the root cause of the stale data to avoid requesting repeated cache invalidation.
• To troubleshoot a site serving stale cached data, review scheduled jobs in Business Manager that can frequently trigger cache invalidation or cache partition invalidation.

To learn more, see:

• Page Caching Best Practices
• Invalidate a Page cache Partition
• Granular Data Replication

Code Replication

The last step of the code replication process from staging to production automatically clears the cache. If you directly deploy code or page changes to production (not recommended), manually clear the cache.

Note If you directly upload code, manually clear the cache regardless of the instance (production, development, or staging) to which code is uploaded.

Data Replication

The last step of the data replication process automatically invalidates and refreshes the cache by default, except in certain cases as described here.

Configure a replication process to skip automatic cache clearing. However, use this feature with caution, because it can lead to inconsistent data in the storefront, the cause of which can be difficult to diagnose. Be sure you understand the scope of the changes that you’re replicating, and keep them as small as possible.

For example, consider the following scenario. Your product description pages are cached for 24 hours, and the page cache is scheduled to be cleared the following night. You notice that several product prices are incorrect in the production instance. First, you correct the prices in Business Manager on the staging instance. Then you replicate the changes to production using a replication process that is configured to skip page cache clearing. This process keeps your price information in sync on both instances, and make sure that the correct product prices appear in baskets (which are never cached).

Skipping the automatic cache refresh also means that your storefront's product description pages show the old, incorrect prices until the scheduled page cache clearing occurs. However, this tradeoff also avoids the performance hit of a production cache refresh.

• When you replicate site-specific data, B2C Commerce clears the page cache for the affected site. This automatic cache refresh doesn’t occur when you only replicate coupons, source codes, Open Commerce API settings, or active data feeds.
• When you replicate global data, B2C Commerce clears the page cache for all affected sites, unless you only replicate geolocations or customer lists.
• When you replicate catalogs, sites, or price books, the cache is automatically cleared. When you replicate only promotions or static content, the cache isn’t automatically cleared.
• When you replicate catalogs, B2C Commerce selectively clears the page cache of affected sites, using the rules described in the following table.

Also, configure a replication process to invalidate page cache partitions only that have replication tasks assigned that match the replication tasks chosen for the replication process. The rest of the storefront's page caches remains untouched. A list of impacted page cache partitions appears on the replication process summary page.

To enable that option:

• Define any page cache partitions on the staging instance.
• Keep all page cache partitions, of all sites, in sync on the staging instance and the target instance (Development or Production) that is subject to get data replicated to.

Use the 'Cache Settings' replication task on each site, and run a data replication to sync page cache partitions if they’re out of sync.

Managing cache partitions now also allows assignment of replication tasks to individual page cache partitions.

For example, a cache partition related to content-specific pages(content slots or content assets) can get assigned replication tasks for specific shared libraries, the site's content library, and content slots.

Troubleshooting Cache Clearing

If you experience issues with the page cache, consider the following tips.

• Before manually clearing the cache in Business Manager, always make sure that the problem isn’t local. Close your browser and clear your local cache to verify.
• To manually clear the cache on the embedded CDN (all production and development environments), click Invalidate next to the Entire Page Cache for Site description. You don't need to also clear the static cache.
• If you don't see an expected change, look for a pattern that can indicate a more specific problem. For example, are images not refreshing? If so, the image provider, such as Scene 7, can have an issue. If a content asset is causing a problem, make sure it has been deployed.