Salesforce B2C Commerce 24.7 > Administering Your Organization > Replication

Page Cache and Replication

Both code and data replication have page cache implications. Certain replication tasks automatically invalidate and refresh the cache, and it can be a good idea to clear the cache manually after running some others.

To access the cache, select Administration > Sites > Manage Sites > sitename > Cache.

Note: In general, Salesforce B2C Commerce automatically clears the page cache only as needed.

Note: For information on caching, see Caching Content.

Clearing the page cache can create a heavy load on the application servers. Only clear the page cache manually when necessary, and avoid clearing it during times of high traffic.

Because a cache command can take up to 15 seconds to reach the web server, there can be a delay before you see the cache update. Account for this delay before reissuing the command.

A production instance has a 15-minute delay until all pages are refreshed for both automatic and manual cache refreshes. This delay ensures load distribution across application servers. On non-production instances, the page cache refreshes immediately.

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), you must manually clear the cache.

Note: If you directly upload code, you must 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.

You can 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 ensures 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 is not automatically cleared.
When you replicate catalogs, B2C Commerce selectively clears the page cache of affected sites, using the rules described in the following table.

Catalogs Replicated	Sites Where the Page Cache Is Cleared
All catalogs for all sites of an organization	All storefront sites of this organization.
A single catalog that is assigned to one or more sites	The sites to which the catalog is assigned.
A product catalog that isn't directly assigned to a site but serves as a product repository for one or more site or navigation catalogs	The sites, as determined programmatically, of storefronts that offer products from the product catalog. The page caches of unrelated storefront sites aren't cleared.

Also, you can 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 is shown on the replication process summary page.

To enable that option:

Any page cache partitions must be defined on the staging instance.
All page cache partitions, of all sites, have to be in sync on 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 by closing your browser and clearing your local cache.
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 have to also clear the static cache.
If you don't see an expected change, look for a pattern that could indicate a more specific problem. For example, are images not refreshing? If so, the image provider, such as Scene 7, could be having an issue. If a content asset is causing a problem, make sure it has been deployed.