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
.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.
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.
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.
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.
If you experience issues with the page cache, consider the following tips.