Explore caching methods in Optimizely CMS 13

Optimizely Content Management System (CMS) supports caching and cache expiration settings for files, resources, and images. CMS manages caching across web front-end servers to minimize database communication. Configure and extend the cache using the methods described in the following sections.

Object cache

Use the object cache to store read-only objects in memory for faster access.

CMS automatically caches objects requested from the API, such as content instances. An event system manages invalidation with support for load-balanced servers.

The object cache improves scalability with an optimistic locking approach. When multiple threads read the same data, they attach to the same database calls to avoid excessive database load for objects not yet cached. See Cache objects.

Output cache

CMS has no built-in output caching of HTML responses. See Response caching (from Microsoft) for adding response caching to an ASP.NET Core application.

📘

Note

Adding response caching can cause a stale response to be delivered.

Response caching can prevent content from updating instantly after publishing from CMS and cause differences among web instances of a load-balanced environment. Do not use response caching if you have Html.RenderEPiServerQuickNavigatorAsync() in a Razor view.

Browser cache

Configure rules for browser (client) caching to control how long static files and dynamically generated pages are cached on the client.

Set a time period in which the client caches static files delivered by CMS. Define how long dynamically generated pages are cached on the client.

File cache

Configure content media cache headers through EPiServer.Web.MediaOptions.

Static file cache

The static file middleware serves static files. To control the caching of these files, see Set HTTP response headers (from Microsoft).

Dynamic Data Store cache

Use Dynamic Data Store (DDS) caching to optimize data access for both compile-time and runtime data types.

Dynamic Data Store (DDS) provides an API and infrastructure for saving, loading, and searching both compile-time data types (.NET object instances) and runtime data types (property bags).

DDS uses a two-level cache:

• The first-level cache is a collection of objects that reside in memory with the context until the context is no longer in scope.
• The second-level cache provides a default in-memory cache implementation to DDS. Objects are in deconstructed form, meaning they do not hold hard references to each other and are invalidated from the cache individually, maximizing cache efficiency. The in-memory implementation decides when and how it releases objects from memory if CMS does not remove them due to updates.