Caching in Composite

This document describes the different cache mechanisms in Composite. The intended audience are developers that need to figure out how to minimize caching in “change and see result” scenarios and developers / administrators that need to tune the system to perform well.

Composite contain a range of cache options raging from caching whole page outputs, XSLT results to caching a specific database result. The mechanisms are versatile enough to cater both static sites and highly personalized sites. When configured correctly the cache mechanisms can ensure that load on the web-server and databases are minimized, greatly increasing performance (up to 5000% with server side full page caching) and scalability.

Full page caching

Composite can cache pages either on the client, on public proxies or on the web server. By default full page caching is turned off. You can enable full page caching by editing the sites configuration file and specify the number of minutes to cache in the fullpagecachetimeout field and what level of full page caching you desire in the fullpagecacheability field.

If the fullpagecachetimeout field is set to "0" (default) and the fullpagecacheability is set to any other value than "NoCache" Composite will not force ASP.NET to use a specific caching scheme. This enables ASP.NET controls hosted on the Composite page to take control and specify page specific caching using the HttpContext.Response.Cache object.

fullpagecacheability

If your site does not feature personalized elements based on cookies, Sessions, logins or other “non URL” data, you can utilize the server side full page caching mechanism. Enabling server side full page caching can increase performance between 300% and 5000%, depending on the existing cache mechanisms used.

You enable server side full page caching by specifying "ServerAndPrivate" in the fullpagecacheability field and the desired number of minutes to cache a page in the fullpagecachetimeout field. These fields are located in the site configuration file. 

If your site do contain personalized content, you can specify "Private" in the fullpagecacheability field, if client side caching is desired.

Strategy “Page”

This strategy will cache pages that are requested without GET and POST parameters. Pages that receive GET or POST parameters, like a search result page, will not be cached. Instead such pages will be processed as if full page caching were disabled.

This strategy works well for sites that does not feature personalized pages, and where dynamic pages that uses GET or POST parameters are either seldom used or are so “user specific” (like a free text search form) that they are not worth caching.

Strategy “ByParams”

This strategy will cache pages both with and without GET and POST parameters. The parameters uniquely identify the cached instance, i.e. a search result page will have multiple cached instances, one for each unique set of parameters.

You should carefully consider using this strategy, since it can consume a great deal of memory.

This strategy works well if your site features dynamic pages that uses GET or POST parameters, and the number of “parameter combinations” is low, while the chance that multiple users will request the same “parameter combinations” is high.

The downside to full page caching

If you enable full page caching you should be aware that changes made to the page as a whole does not show up, until the cache time expires. This is really not an issue when it comes to page content, since you just delay the content changes until the page is removed from the full page cache, but if your pages contain elements like a list of news teasers, you should be aware that pages cached prior to the publication of a news item wont feature this news in its list, while other pages generated after the news were publicized will show the news teaser. You might experience a “now you see it, now you don’t” scenario. This goes for other “site wide” content changes, like changing the templates etc.

As such you should consider not using full page caching, or setting the timeout to a low value, if the site contains “common elements” like news lists etc. that are updated frequently.

Plug-in caching

The Data Query and XSL Render plug-ins can cache elements individually. A page can contain x XSL Render instances that can have individual cache settings, and a XSL Render instance can use x Data Queries that can have individual cache settings. This gives you very fine grained control over caching, and ensures that “common elements” can be cached and user specific elements can be fetched appropriately.

You specify the cache time on the individual items. You can specify that the results from the Data Query or XSL transformation should be cached between 5 seconds and 24 hours, or disable caching on the element all together. The option “Composite Default cache time” currently caches for 30 seconds.

When Data Query results and results from XSL transformations are cached, the key used to identify the cached element is the parameters used by the (underlying) Data Queries.

Example: You have a Data Query Q1 that takes no parameters – caching this will always return 1 instance. If you have a Data Query Q2 that takes [COM]DocumentID as parameter, the current document id is used as key. If you have a XSL Render instance that use multiple Data Queries it will build a unique cache key based on the combined parameters for the underlying Data Queries.

If your XSL Render instance uses run time values like cookies, session state, form input etc., and some of the values you use in the XSL are notused as Data Query parameters, then you should turn caching off, since the run time values will not be part of the cache key. Remember that only Data Query parameter values are used to build the key.

Data Query and XSL settings are cached for 30 seconds

By default the render kernel will cache Data Query and XSL settings for 30 seconds. This include the SQL commands to execute, their parameter layout, the XSL document used to do the transformation etc. This does not include the actual XML results from the Data Queries or the result of the XSLT – you control the cache time for these “data related” elements your self.

To make development more transparent caching on Data Query and XSL settings are disabled, if the settings has been changed within the last 15 minutes. This ensures that you can work with Data Queries and XSL and see the result right away. When the settings has not been changed in 15 minutes, caching will kick in,

Composite render kernel caching

The Composite Render kernel will cache elements like templates, page title, content etc. according to the datacachetimeout value stated in the sites configuration file.

While you develop the site you should consider setting this value to 0, thereby disabling caching of templates, pages etc.

You should increase this value when you launch the site, by setting the datacachetimeout to the number of minutes to cache elements. The downside to enable the Composite Render kernel cache is that changes to pages can potentially take x minutes to appear on the public site, but the up side is a noticeable performance increase.

Caching in load balanced environments

If you run Composite in a load balanced environment, i.e. you have multiple web-servers serving up the same site, you should consider the following pros and cons.

The more you cache, the less load there will be on the SQL Server database and other databases used by the website. Having a low load on these systems increase your ability to add more web-servers without having to “beef up” the database systems, and as such increases the sites ability to scale.

The downside to enabling caching on load balanced environments is that the web-servers can be “out of sync” with regard to what they have cached, and users that browse around the site might get different results, like a news teaser showing up on one page and not showing up on another, until the all servers in the farm have a cache the reflect recent changes. If your load balancing strategy sends users to the same server at each hit, they should not experience this behavior. You can also consider setting the cache time to a minimum, and accept the potential “out of sync behavior” that might occur.

The “now it’s there, now it’s not” behavior is also a potential problem on single server sites that utilize full page caching.