Part 4: Output Caching in SharePoint 2010

A SharePoint Publishing site can also be configured to make use of the ASP.NET output cache to store rendered ASPX pages in memory. You can only make use of this cache when the Publishing features are activated on your site collection. This means that only publishing pages can be cached.

When a Publishing page is first requested, SharePoint assembles the page dynamically: it first fetches the page layout from the content database and then fetches the contents of the page. The page layout comes from the content database; the data on the page can be data coming from the content database or files already cached in the BLOB cache. Once the page is assembled, the resulting HTML stream is stored in the output cache. On a next request the HTML is served from the cache: the controls are not created, the page life cycle doesn’t start, and no code-behind is executed. The only things that are not covered by the output cache, are images and other resources like JavaScript files and CSS files. These need to be handled by other caching mechanisms.

This way pages are served more quickly and CPU load is reduced on the web front-end servers and on the SQL Server content database because pages won’t have to be reassembled on each request. Output caching is considered as one of the most performance improving techniques.

Important to notice is that the resulting HTML is stored in memory. This means that no server-side code is executed when the page is requested again. This can be a problem if you have controls on your page that need to be refreshed on each page request. There are different techniques that can circumvent this behavior for this specific control. More on this in part 23 on partial caching.

SharePoint also stores different versions of the cached page, based on the permissions of the users who are requesting the page. For each set of permissions there will be a cached version. But if a site is configured for anonymous access, the web front-end servers won’t even have to request additional data from SQL Server to do a permission check, which results in better performance.

The output cache is an in-memory cache on each web front-end. There is a formula for calculating the memory requirements:

(2 x page size) + 32 KB of memory per rendered copy of a page

Configuring the output cache

Output cache can be configured at site collection level but it can only be configured if the Publishing feature is activated. You can find a link to the output cache settings page in the Site Collection Administration section of the site settings page of the root site.

By default, the output cache is turned off. You can enable the output cache by checking the Enable output cache checkbox.

In the next section you can apply cache profiles. You can apply a different cache profile for Anonymous access and a different one for authenticated users. As you will see in next section, SharePoint comes with an out of the box cache profile for each type of access.

If you only want to configure output cache for anonymous access, you can leave the disabled option for authenticated users. In that case no output caching will be done when in authenticated mode.

In the 3th section you can decide whether you want to apply the same cache profiles for all sub sites or not. In general the same cache profiles are applied for all sites within the same site collection. In that case you leave this checkbox unchecked. But it is possible that you need another caching behavior on your Search center because you don’t want your results cached externally. In that case you check this check box, enabling the possibility to configure different cache profiles on sub site level.

The second checkbox “Page Layouts can use a different page output cache profile” is to allow the application of different cache profiles for one or more specific page layouts. If you don’t have your search results page in a separate search center, then it can be necessary to check this option.

The last section is an option to enable a debug message in the HTML at the end of the page. The message informs whether the page is served from cache and which cache profile is used, or the reason why the page is not cached. You can see this debug message by going to the source of the page.

You can find more details on how to configure output cache here.

Once the output cache is functioning, you will see that it also has an impact on the http response headers that are added to the first http request that requests the HTML document. In my sample site, output cache is configured to store pages in cache for 15 minutes.The next screenshot shows that the page is placed in output cache at

The next screenshot shows that the HTML is valid till, exactly 15 minutes after the page was placed in cache.

Cache Profiles

As already mentioned in the introduction, the output cache is an ASP.NET feature. SharePoint adds cache profiles to it. A cache profile is a collection of caching settings that you can give a name and apply to sites and pages. The SharePoint Publishing feature comes with a set of default cache profiles. They organize caching behavior based on a user’s access rights to a site.  For each permission set, a version of the page is stored in the output cache. The next user with the same access rights gets the same page version from the cache.

A cache profile can also be configured to store a version of the page per different browser type because pages are rendered a bit differently on a different browser. In fact that’s one of the default settings on the cache profile for anonymous access.

SharePoint offers a number of out of the box cache profiles. You can find a link to the cache profile settings page in the Site Collection Administration section of the site settings page of the root site.

The most frequently used cache profiles are the Public Internet cache profile for anonymous visitors and the Extranet cache profile for authenticated users. You can view or edit existing profiles.

Cache invalidation is defined within the cache profiles.

In next sections we will look at a number of the out of the box cache profiles, but you can also define your own custom cache profiles making use of the Vary By principle that exists in ASP.NET.

The Public Internet (Purely Anonymous) cache profile

This profile is specifically for anonymous access and will typically do no ACL check when a page is requested. It will serve the same version of the page to each user.

The duration is configurable in seconds. Depending on the settings a version of the page is cached per browser version. If you keep your CSS and JavaScript to a level that all browsers can handle it, you can remove this setting. If you code against browser then you have to leave this option as is.

This cache profile does not check for changes each time the page is requested but only invalidates when the specified duration elapses.

You can configure additional settings for this profile. It is possible that you add query string parameters to the URL. The output cache will see this as a different request and build the page again. If you want to keep your page in cache, you can set the Vary By Query String Parameters by specifying the different query string parameters for which you want the output cache to save  a version of the page per value of the specified query string parameter(s). You can also enter an asterisk (*) as value to make sure that a version is stored for any difference in query string parameters.

Another possibility is to specify a Vary by HTTP Header. This will make the output cache save a version of every page that has a different value for the specified HTTP header(s).

The Cacheability setting is set to ServerAndPrivate by default.

The following table shows the different cacheability settings.

Type of cacheability	Description
NoCache	Prevents the page from being cached. This setting adds the following HTTP Response header Cache-Control: no-cache.
Private	Only allows the page to be cached on the client browser, and not on in the proxy cache of providers. This setting adds the following HTTP Response header Cache-Control: private.
Server	Only allows for caching the page on the server. This setting adds the following HTTP Response header Cache-Control: no-cache to indicate to the browser that the resource may not be cached.
ServerAndNoCache	Only allows for caching the page on the server and is equivalent to “Server”. This setting adds the following HTTP Response header Cache-Control: no-cache.
Public	Allows the page to be cached on server, client browser and proxies. This setting adds the following HTTP Response header Cache-Control: public, indicating that the resource can also be cached by browser and proxies.
ServerAndPrivate	Allows the page to be cached on the server and the client browser but not on the cache of proxy servers. This setting adds the following HTTP Response header Cache-Control: private.

The Extranet (Published Site) cache profile

This cache profile is for authoring scenarios. The settings for this profile are quit different than for the anonymous profile. It does perform an ACL check to verify that the user who requests the page has the rights to view this page. This check is performed before serving the page and  causes a small performance decrease. The Vary By User Rights option is checked by default and  resulting the fact that  a copy of the page is stored in cache for each type of user access rights.

Out of the box it also keeps a copy per browser type.

It also checks for site updates on each request. In case of a change the page is flushed from the cache, reassembled and stored again in cache before it is returned to the user. Setting this attribute can reduce performance on a site that is frequently modified, but it ensures that the latest content is always available. That’s the reason why it is more appropriate for authoring scenarios. Regardless of this setting, cached pages still expire when the duration has been exceeded.

Vary By Query String Parameters

You can use this setting to specify a query string parameter for which you want to store a different version in the cache. Take for example following URL:

http://www.xxx.be/index.aspx?print=yes

It is possible that you use this query string parameter to load your page differently in case you want to generate a printable version of your page. On the server you can for example test on this query string parameter and use a different master page in order to generate that printable version. If so, you will want to keep both versions in the output cache. To achieve this, you have to set the Vary By  Query String Parameters to the string “print” (without quotes).

If you want to vary the pages based on multiple query string parameters, you can to list them separated by a colon (,) and no blank.

You can also use the value * and the value None. The value * will keep a version for each different querystring parameter while the None value will only store one version of the page in the output cache.

Vary By HTTP Header

ASP.NET allows you to cache multiple versions of a page depending on the value of an HTTP header that you specify. You can specify caching by a single header, multiple headers, or all headers passed to your application when the page is requested. You could for example want to cache different versions of the page based on the Accept-Language header.

You could also want to vary the pages in the output cache based on the cookies. In that case you have to set the Vary By HTTP Header to “Cookie” (without quotes).

If you want to vary the cached content by multiple headers, include a list of header names separated by semicolons (;). If you want to vary the cached content by all header values, set the VaryByHeader attribute to an asterisk (*).

Vary By Custom Parameter

In the cache profile for anonymous access, this setting is set to Browser by default. It means that a different version of the page will be cached for every browser that visits the page.

You could also vary the pages based on a different custom parameter.

Configuring different cache profiles for sub sites

On the settings page where you can configure output cache you have an option where you can define that you want to allow sub sites to use different cache profiles:

This can be useful when one of your sub sites is a search center.

Once you check this option, additional options become available on the sub sites. On the site settings page under the Site Administration section you now have an additional hyperlink Site output cache.

Here you can define the cache profiles for the site. If you want to apply this selection to the the sub sites of this site, you can check the option Apply these settings to all sub sites.

Configuring different cache profiles for different page layouts

On the settings page where you can configure output cache you have an option where you can define that you want to allow page layouts to use different cache profiles.

This can be useful when one of your page layouts is a search results page layout.

Once your check this option, additional options become available on the page layout properties page. If you now want to apply different cache profiles for one or more page layouts, you can navigate to the site settings page. Under the Galleries section click the Master pages and page layouts hyperlink to open the master page gallery. You can check out the page layout and edit its properties. There you can select the different cache profiles you want to apply on the selected page layout.

For the search results page you will typically leave sthe selection to None. It’s in situations like this that you can benefit from custom cache profiles that have a slightly different set of settings than the out of the box cache profiles.

Configure output cache using PowerShell

Unfortunately there are no out of the box PowerShell cmdlets that let you configure output cache but you can use the server-side object model, more specifically the SiteCacheSettingsWriter class. Setting the EnableCache property to true will enable output cache:

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint.Publishing”)
$cacheSettings = new-object Microsoft.SharePoint.Publishing.SiteCacheSettingsWriter($Url); 
$cacheSettings.EnableCache = $true; 
$cacheSettings.Update();

You can apply the anonymous cache profile like this:

SetAnonymousPageCacheProfileId($site, 1)

The $site object represents the site collection and the integer value represents the ID of the cache profile. Cache profiles are stored in a dedicated SharePoint list on the root web of your site collection.

You can apply the authenticated cache profile in a similar way:

SetAuthenticatedPageCacheProfileId($site, 2);

If you want to configure that sub sites can apply different cache profile, you set the following property to true:

$cacheSettings.AllowPublishingWebPageOverrides = $true;

The same goes for applying different cache profiles for different page layouts:

$cacheSettings.AllowLayoutPageOverrides = $true;

The debug message can be set as follows:

$cacheSettings.EnableDebuggingOutput = $true;

Override Output Cache settings on Web Application level

In general, output caching is configured at site collection level. But you can override individual settings with settings that apply to all site collections within a SharePoint web application. You do this by changing the useCacheProfileOverrides attribute of the OutputCacheProfiles element in the web.config of the web application:

<OutputCacheProfiles useCacheProfileOverrides="false" varyByHeader="" varyByParam="*"  varyByCustom="" varyByRights="true" cacheForEditRights="false" />

The different attributes have the following meaning:

• useCacheProfileOverrides: this attribute is set to false by default. By setting it to true you define that output cache settings need to be applied to all site collections in the web application.
• varyByHeader
• varyByParam
• varyByCustom
• varyByRights: The default value is true. But you can set this attribute to false if you need to serve the same page to users with different permission sets. This is useful when you break permissions on f.e. an assets library while your content pages are under the same permissions.
• cacheForEditRights: The default value is false to prevent people with edit rights from seeing cached pages.

Site Pages

Any page that is not a publishing page but that is created in a document library, is called a site page. These pages also end up in the content database but are not subject to output caching. By default these pages get an expiration date that is 15 days in the past and are set for private cache. Client browsers can cache the page but before the page is rendered again, the browser will check against the server if the page is still valid. If so, the site page will be served from browser cache.

Develop your own CacheProfile

If you want your pages in the output cache to invalidate based on a complete custom logic that cannot be achieved using one of the settings in the Cache Profile settings page, you can also develop your own CacheProfile.

This class must implement the IvaryByCustomHandler interface.

The assembly must be deployed in the Global Assembly Cache (GAC) and must be registered in the global.asax.

You can also create a cache profile using PowerShell.