Similar content

Loading

Powered by Canoo FindIT.

Cache

Magnolia CMS employs a web cache to store server responses so that future requests for the same content can be served faster. Using a cache reduces the amount of information that needs to be transmitted across the network, easing the bandwidth and processing requirements and improving responsiveness.

Cache filter

Caching is performed by the Cache filter which is part of standard Magnolia CMS filter chain. The Cache filter attempts to serve the requested content directly from the cache store. If the content is not available, the filter passes the request on to the CMS part of the filter chain. On the return trip the filter reads the content from the response and stores it in the cache store for future use.

Policy configuration

Magnolia CMS allows you to define several alternative cache configurations in the Cache module and select one of them by setting the cacheConfigurationName parameter in the Cache filter. The chosen configuration is read into a JavaBean using the Content2Bean mechanism, which makes it dynamically available to your own module code.

Caching behavior for each configuration is defined with policies:

  • Server cache policy defines whether the requested content should be cached or not. The standard Magnolia CMS way to make such decisions is with voters. Voters are used whenever configuration values are not assigned at start-up but depend on rules. Voters evaluate a rule such as "should content residing at this URL be cached" and return a positive or negative response. By default, all content on public instances is cached except the AdminCentral UI at /.magnolia.
  • Client (browser) cache policy defines how long the browser may cache a document. The time is passed to the browser in the response header. The default FixedDuration option instructs the browser to cache the document for 30 minutes. Another option is Never which tells the browser to do nothing.
  • Flush policy defines when to flush the cache. The default configuration observes changes in a repository and flushes the cache if new or modified content is detected. You can flush the cache completely, partially or not at all. Multiple flush policies can be registered. Each module can register its own flush policy (or multiple policies) and be notified about new or modified content in each repository.
  • Executors are actions taken once a caching decision has been made. There are three possible actions. useCache retrieves the cached item from the cache and streams it to the client, store stores the response in the cache for future use, and bypass skips caching altogether.

Caching while developing

Important! The system caches resources such as JavaScript files and CSS files on the author instance by default to make authoring more responsive. When you develop, you want to disable this behavior. Set the magnolia.develop property to true in the default magnolia.properties file.

How caching works

When a request arrives to the Cache filter, the filter passes it first to the browser cache policy. In case content has not been modified and the client already has the latest version, the browser cache policy instructs the filter to simply respond with "304 Not Modified".

If content has been modified or it does not exist in the cache, the filter passes the request to the server cache policy. Server cache policy analyses the request and replies with the expected behavior. Based on the expected behavior the filter invokes the appropriate executor. This mechanism allows you to add and remove executors and use them by changing the current cache policy to a different one.

Ehcache back end

Magnolia CMS uses Ehcache for its back-end cache functionality. Ehcache is a robust, proven and full-featured cache product which has made it the most widely-used Java cache. You can use another cache engine as long as you implement Java interfaces that allow you to configure caching behavior from AdminCentral.

Advanced cache strategies

The Advanced Cache module is a collection of cache strategies to help minimize load on the server while ensuring fresh content is served to users.

  • Serve old content while re-caching. When using this strategy, cache will not be completely cleaned when content update is detected. All cached entries are retained. When the first request comes in after content update, generation of a fresh cache entry is triggered while further requests for the same entry are served from old cache content until the new entry is ready. Magnolia will wait 10 seconds by default while still serving the old version of the content before attempting to re-cache. The waiting time is configurable.
  • Eager re-caching. When using this strategy, cache will keep a list of most often served entries and attempts to refresh those as soon as an update of content is detected. All other entries are re-cached when requested again, as is the case with the strategy above. The number and lifetime of the most-served content entries is configurable. Statistics about served pages are kept forever by default but you can force Magnolia CMS to clean them after each content update.