Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
The need to cache content is very different in developing, staging or production environments. If your system relies heavily on cache for performance the system may be misconfigured or it suffers from too small servers.
With Magnolia you can cache basically every object beyond the well known page caching, for further details see caching arbitrary objects.
Magnolia caches content on a page level by default. This means that page is the smallest unit you can cache with the standard Cache module. The Dynamic Page Caching add-on allows you to cache fragments of a page.
Static Web resources such as CSS and JavaScript as well as aggregations of such resources are cached.
Magnolia has a separate Digital asset management module. Assets (for example images) and asset renditions served directly from Magnolia are cached by default. Assets served from external an DAM such as Cumulus DAM connector or Amazon S3 Connector module are not cached by Magnolia.
The cache policy - what should be cached and what not - is highly customizable according to your requirements.
You can define flush policies - rules when the cache must be flushed. For instance, you can make flush procedure depend on changes on JCR repositories.
The cache module comes with a configurable GZip filter to enable Gzip compression. To serve content compressed in the GZip format is a common and widespread approach to decrease network demands. All text based files (HTML, CSS, JavaScript) are compressed by default.
Ehcache is Magnolia's default third-party low level cache implementation. (For more details see below.)
Alternative third-party low level cache implementation. (For more details see below.)
The Cache Browser app runs on an author instance and allows you to delete cache items on a granular level. The app will delete cached items on all the public instances - independent of your public instances setup - be it a single instance or a complex cluster.
When using Personalization (Enterprise Standard), pages that have personalized content are not cached by default. You can enable caching with Advanced Cache for Personalization (Enterprise Pro).
Dynamic page caching allows you to cache fragments of a page which also contains parts which cannot be cached. DCP uses the SiteMesh module.
Magnolia cache uses established third-party libraries for the low level functions. Depending on your production environment, one cache implementation may fit better than another. Please contact Magnolia Services to get the the best cache strategy for your project and server setup.
By default Magnolia uses Ehcache. The third party library comes with and is configured with Ehcache module module.
Cache module version 5.4 (bundled with Magnolia 5.4) updated Ehcache from 1.5 to 2.10.
Ehcache stores cached content to disk. On version 1.5, cached content was always kept on the disk as long as flushing was not proactively requested. Version 2.10 deletes cached items when the server is stopped. As a consequence, when you restart the server, the cache store must be rebuilt again. Since a production system is stopped rarely the loss of the persistent cache store is typically not a problem. A production server is typically stopped only when updating Magnolia or if the server crashes.
However, if you want to use a cache that will persist between restarts of Magnolia, use the Memcached implementation.
Alternative implementation - Memcached
Memcached is high-performance, distributed memory object caching system. Magnolia's Memcached implementation brings you the advantages of a distributed cache:
Community Edition:
Enterprise Standard:
Enterprise Pro: