Page History

...

How caching works

...

Image Added

How caching works

Caching is performed by the Cache filter, which is part of the standard Magnolia filter chain. When a request arrives to the Cache filter, the filter passes it to the browser cache policy.

• Content not modified: If a client has the latest version of content (i.e. not modified), the browser cache policy instructs the filter to respond with "304 Not Modified".
• Modified content: If content has been modified or does not exist in the cache, the filter passes the request to the server cache policy. Server cache policy then analyses the request and replies with the expected behavior. The filter then invokes the appropriate executor. This mechanism allows you to add, remove and use executors by changing the current cache policy.
• Content not modifiedavailable: If a client has the latest version of content (i.e. not modified), the browser cache policy instructs the filter to respond with "304 Not Modified".
• Modified content: If content has been modified or does not exist in the cache, the filter passes the request to the server cache policy. Server cache policy then analyses the request and replies with the expected behavior. The filter then invokes the appropriate executor. This mechanism allows you to add, remove and use executors by changing the current cache policy.
• Content not available: If the content is not available, the filter passes the request on to Magnolia. On the return trip, the filter reads the content from the response and stores it in the cache store for future use. Flush policy is completely independent of this chain and reacts on content changes rather than content served.

Image Removed

Configuration

Cache configurations are defined in /modules/cache/config/contentCaching/. Within each configuration you can define:

• What to cache.
• When to flush the cache.
• What header data to pass to browsers.

• Specific implementations of tasks.

...

...

• content is not available, the filter passes the request on to Magnolia. On the return trip, the filter reads the content from the response and stores it in the cache store for future use. Flush policy is completely independent of this chain and reacts on content changes rather than content served.

Image Added

Configuration

Cache configurations are defined in /modules/cache/config/contentCaching/. Within each configuration you can define:

• What to cache.
• When to flush the cache.
• What header data to pass to browsers.

• Specific implementations of tasks.

Image Added

To select one of the cache configurations, set the defaultContentCachingConfigurationName parameter in the Cache filter. The chosen configuration is read into a JavaBean using the Node2Bean mechanism, making it dynamically available to your own module code.

Image Added

Policy configuration

Caching behavior for each configuration is defined with policies.

Server cache policy

This policy defines whether the requested content should be cached or not. The decision to cache relies on voters, which are used whenever configuration values are not assigned at startup 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. Server cache policy is configured in /modules/cache/config/contentCaching/defaultPageCache/cachePolicy. The default implementation (

Image Added

Cache key generator

You can define a custom cache key generator or configure the default one to meet your needs.

Image Added 

Client (browser) cache policy

Allows for different policies for different content types. Voters are used to define the caching rules. These policies define how long the browser may cache each content type. The time is passed to the browser in the response header. The 

...

...

...

...

...

...

...

...

To select one of the cache configurations, set the defaultContentCachingConfigurationName parameter in the Cache filter. The chosen configuration is read into a JavaBean using the Node2Bean mechanism, making it dynamically available to your own module code.

...

...

...

...

...

...

...

Policy configuration

Caching behavior for each configuration is defined with policies.

Server cache policy

This policy defines whether the requested content should be cached or not. The decision to cache relies on voters, which are used whenever configuration values are not assigned at startup 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. Server cache policy is configured in /modules/cache/config/contentCaching/defaultPageCache/cachePolicy. The default implementation (

...

...

...

...

...

...

...

...

...

...

Cache key generator

You can define a custom cache key generator or configure the default one to meet your needs.

...

...

...

...

...

...

...

...

...

...

...

...

info.magnolia.module.cache.cachekey.DefaultCacheKeyGenerator

...

...

info.magnolia.module.cache.cachepolicy.Default

...

browser to do nothing. Client cache policy is configured in /modules/cache/config/contentCaching/defaultPageCache/browserCachePolicy. 

Image Added

Flush policy

The Flush policy defines when to flush the cache. There are two policies installed per default.

Changes in workspaces

This configuration observes changes (activation, import, edit) in a workspace and flushes the cache if new or modified content is detected. Cache can be flushed completely, partially or not at all. Each module can register its own flush policy (or multiple policies) and receive notification about new or modified content in each workspace. Flush policies are informed about changes in observed workspaces. The list of observed workspaces can be defined per policy under the workspaces subnode of each policy or all workspaces will trigger cache flush unless defined under excludedWorkspaces subnode (default configuration). If your custom workspace doesn't affect the content of pages, you should register it under excludedWorkspaces, otherwise, a change in your workspace will unnecessarily flush the cache.

Changes in light modules

 Magnolia 5.6.1+: A change in the light modules folder may also flush the server cache. See /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/lightModule/pathToCacheMappings/defaultPageCache with the pattern property, which specifies the pattern for the operation. The default value is .*/(templates|webresources|i18n)/.* .

Image Added

Executors

These are actions taken once a caching decision has been made. There are three possible actions:

1. useCache: Retrieves the cached item from the cache and streams it to the client.
2. store: Stores the response in the cache for future use.
3. bypass: Skips caching. This is useful for content that cannot or should not be cached.

Executors can be configured at /modules/cache/config/contentCaching/defaultPageCache/executors. Each of the executors is also responsible for configuring expiration headers.

Image Added

Compression

Compression is a simple and effective way to save bandwidth and speed up your site. It is a common practice used by Google and Yahoo! for example. (How to Optimize Your Site with GZIP Compression is a great general introduction to the topic.) Compression is performed in the gzip filter, configured in /server/filters/gzip}. When a client requests a resource such as index.html, Magnolia delivers it zipped. A typical HTML page is compressed to 20% of its original size. So if your page is 100 kB uncompressed, it is 20 kB compressed. To improve performance further, zipped content is streamed from the repository to the client rather than read into memory first.

Configuring

You can configure which content types to compress. By default, the gzip filter bypasses compression for HTML, JavaScript and CSS because they are explicitly selected for compression in the Cache module configuration. These types can be compressed efficiently because they are text. The decision to compress a particular content type is made with voters. Voters are used whenever configuration values are not assigned at startup but depend on rules instead. In the Cache module configuration there are three voting rules based on content type:

• text/html: HTML.
• application/x-javascript: JavaScript.

• text/css: Cascading Style Sheets.

Image Added

To add more content types, such as XML, create a numbered property under allowed. Use the Internet media type (MIME type) as value. Here are some common media types:

• application/xhtml+xml: XHTML.
• text/csv: Comma-separated value.
• text/plain: Textual data.
• text/xml: Extensible Markup Language.
• application/pdf: Portable Document Format.

As a rule, compressing the HTML, JavaScript and CSS is sufficient; it is not necessary to compress binary content such as images. During the process, the browser sends a header telling the server that it accepts compressed content: Accept-Encoding: gzip. Note that Magnolia does not cache big binaries.

Internet Explorer 6

Note that while all modern browsers support compression, some older browsers do not, notably Internet Explorer 6 before Service Pack 2. To get around this, Magnolia uses a userAgent voter that rejects compression and delivers uncompressed content if the browser identifies itself as IE6 in the User-Agent field in request headers.

Image Added

Testing compression

To test your compression configuration, use a tool such as  Web-Sniffer  that allows you to change the Accept, Encoding and User-Agent sent headers easily. Here's what the headers look like when the Magnolia demo site home page is submitted to the sniffer.

Request header:

GET /demo-project.html HTTP/1.1 Host: demopublic.magnolia-cms.com 
Connection: close User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 
de; rv:1.9) Gecko/2008052906 Firefox/3.0 Accept-Encoding: gzip 
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7 Cache-Control: no 
Accept-Language: de,en;q=0.7,en-us;q=0.3 Referer: http://web-sniffer.net

Response header:

Status: HTTP/1.1 200 OK Date: Fri, 23 Jul 2010 07:45:10 GMT Server: 
Apache/2.2.9 X-Magnolia-Registration: Registered Cache-Control: 
max-age=900 Last-Modified: Thu, 01 Jul 2010 14:03:12 GMT 
Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 3852 
Connection: close Content-Type: text/html;charset=UTF-8

Advanced strategies

In DX Core, advanced caching strategies are available in separate Advanced Cache modules .

Commands

Cache related commands are in the cache catalog:

• flushAll: Completely flushes all caches. (Note that the imaging workspace - which technically is not a cache - is not flushed with this command.)
• flushByUUID: Completely flushes all entries related to a given UUID from all available caches. This command expects repository and uuid as parameters.
• flushNamedCache: Completely flushes a cache by name. Default cache names are default and uuid-key-mapping.

Cached URLs

By default, the following URLs are cached:

• On public instance everything except /.magnolia/* which is AdminCentral.
• On author instance all static resources /.resources/* if magnolia.develop property is set to false.

Cache strategies

The system caches resources such as JavaScript files and CSS files on the author instance by default to make authoring more responsive. Disable this behavior when developing. Set the magnolia.develop property to true in the default magnolia.properties file. For more complex configurations, you need to adjust the configuration under the /modules/cache/config/contentCaching/defaultPageCache/cachePolicy node

Excluding content from cache

There are various reasons why you may wish to exclude content from cache. For example, you may have components that query an external data source dynamically. The rendered HTML changes even if the content of the Magnolia page has not changed. When we say cached content we mean the rendered output generated by Magnolia itself, the actual content of the page. When you exclude a page from cache you tell Magnolia that it should re-render that content every time the page is requested by a user.

Configuring an exclusion

The first option for excluding content from cache is to configure an exclusion in the cache policy. The example below excludes all pages whose URL starts with /.magnolia. This means that AdminCentral pages are not cached.

Image Added

Client (browser) cache policy

Allows for different policies for different content types. Voters are used to define the caching rules. These policies define how long the browser may cache each content type. The time is passed to the browser in the response header. The 

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Flush policy

The Flush policy defines when to flush the cache. There are two policies installed per default.

Changes in workspaces

This configuration observes changes (activation, import, edit) in a workspace and flushes the cache if new or modified content is detected. Cache can be flushed completely, partially or not at all. Each module can register its own flush policy (or multiple policies) and receive notification about new or modified content in each workspace. Flush policies are informed about changes in observed workspaces. The list of observed workspaces can be defined per policy under the workspaces subnode of each policy or all workspaces will trigger cache flush unless defined under excludedWorkspaces subnode (default configuration). If your custom workspace doesn't affect the content of pages, you should register it under excludedWorkspaces, otherwise, a change in your workspace will unnecessarily flush the cache.

Changes in light modules

 Magnolia 5.6.1+: A change in the light modules folder may also flush the server cache. See /modules/cache/config/contentCaching/defaultPageCache/flushPolicy/policies/lightModule/pathToCacheMappings/defaultPageCache with the pattern property, which specifies the pattern for the operation. The default value is .*/(templates|webresources|i18n)/.* .

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Executors

These are actions taken once a caching decision has been made. There are three possible actions:

1. useCache: Retrieves the cached item from the cache and streams it to the client.
2. store: Stores the response in the cache for future use.
3. bypass: Skips caching. This is useful for content that cannot or should not be cached.

Executors can be configured at /modules/cache/config/contentCaching/defaultPageCache/executors. Each of the executors is also responsible for configuring expiration headers.

...

...

...

...

...

...

Compression

Compression is a simple and effective way to save bandwidth and speed up your site. It is a common practice used by Google and Yahoo! for example. (How to Optimize Your Site with GZIP Compression is a great general introduction to the topic.) Compression is performed in the gzip filter, configured in /server/filters/gzip}. When a client requests a resource such as index.html, Magnolia delivers it zipped. A typical HTML page is compressed to 20% of its original size. So if your page is 100 kB uncompressed, it is 20 kB compressed. To improve performance further, zipped content is streamed from the repository to the client rather than read into memory first.

Configuring

You can configure which content types to compress. By default, the gzip filter bypasses compression for HTML, JavaScript and CSS because they are explicitly selected for compression in the Cache module configuration. These types can be compressed efficiently because they are text. The decision to compress a particular content type is made with voters. Voters are used whenever configuration values are not assigned at startup but depend on rules instead. In the Cache module configuration there are three voting rules based on content type:

• text/html: HTML.
• application/x-javascript: JavaScript.

• text/css: Cascading Style Sheets.

...

...

...

...

...

...

...

...

...

...

...

...

To add more content types, such as XML, create a numbered property under allowed. Use the Internet media type (MIME type) as value. Here are some common media types:

• application/xhtml+xml: XHTML.
• text/csv: Comma-separated value.
• text/plain: Textual data.
• text/xml: Extensible Markup Language.
• application/pdf: Portable Document Format.

As a rule, compressing the HTML, JavaScript and CSS is sufficient; it is not necessary to compress binary content such as images. During the process, the browser sends a header telling the server that it accepts compressed content: Accept-Encoding: gzip. Note that Magnolia does not cache big binaries.

Internet Explorer 6

Note that while all modern browsers support compression, some older browsers do not, notably Internet Explorer 6 before Service Pack 2. To get around this, Magnolia uses a userAgent voter that rejects compression and delivers uncompressed content if the browser identifies itself as IE6 in the User-Agent field in request headers.

...

...

...

...

...

...

...

...

...

Testing compression

To test your compression configuration, use a tool such as  Web-Sniffer  that allows you to change the Accept, Encoding and User-Agent sent headers easily. Here's what the headers look like when the Magnolia demo site home page is submitted to the sniffer.

Request header:

GET /demo-project.html HTTP/1.1 Host: demopublic.magnolia-cms.com 
Connection: close User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; 
de; rv:1.9) Gecko/2008052906 Firefox/3.0 Accept-Encoding: gzip 
Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7 Cache-Control: no 
Accept-Language: de,en;q=0.7,en-us;q=0.3 Referer: http://web-sniffer.net

Response header:

Status: HTTP/1.1 200 OK Date: Fri, 23 Jul 2010 07:45:10 GMT Server: 
Apache/2.2.9 X-Magnolia-Registration: Registered Cache-Control: 
max-age=900 Last-Modified: Thu, 01 Jul 2010 14:03:12 GMT 
Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 3852 
Connection: close Content-Type: text/html;charset=UTF-8

Advanced strategies

In DX Core, advanced caching strategies are available in separate Advanced Cache modules .

Commands

Cache related commands are in the cache catalog:

• flushAll: Completely flushes all caches. (Note that the imaging workspace - which technically is not a cache - is not flushed with this command.)
• flushByUUID: Completely flushes all entries related to a given UUID from all available caches. This command expects repository and uuid as parameters.
• flushNamedCache: Completely flushes a cache by name. Default cache names are default and uuid-key-mapping.

Cached URLs

By default, the following URLs are cached:

• On public instance everything except /.magnolia/* which is AdminCentral.
• On author instance all static resources /.resources/* if magnolia.develop property is set to false.

Cache strategies

The system caches resources such as JavaScript files and CSS files on the author instance by default to make authoring more responsive. Disable this behavior when developing. Set the magnolia.develop property to true in the default magnolia.properties file. For more complex configurations, you need to adjust the configuration under the /modules/cache/config/contentCaching/defaultPageCache/cachePolicy node

Excluding content from cache

There are various reasons why you may wish to exclude content from cache. For example, you may have components that query an external data source dynamically. The rendered HTML changes even if the content of the Magnolia page has not changed. When we say cached content we mean the rendered output generated by Magnolia itself, the actual content of the page. When you exclude a page from cache you tell Magnolia that it should re-render that content every time the page is requested by a user.

Configuring an exclusion

The first option for excluding content from cache is to configure an exclusion in the cache policy. The example below excludes all pages whose URL starts with /.magnolia. This means that AdminCentral pages are not cached.

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

Implementing a custom cache policy

...