Caching in Office SharePoint Server 2007

Microsoft Office SharePoint Server 2007 includes advanced caching capabilities to maximize the performance of the Web sites. This article describes the different kinds of caching available, and how to optimize caching for your specific deployment requirements.

The following table shows the available kinds of caching and where each type is implemented.

Use this kind of caching…

At the…

Notes

Output caching and cache profiles

Individual page level

Ideal for heavily accessed Web sites that do not have to frequently present new content.

Object caching

Individual Web Part control, field control, and content level

Includes cross-list query caching and navigation caching

Disk-based caching for binary large objects (BLOBs)

Individual BLOB level

Supports .gif, .jpg, .js, .css, and other image, sound, and code files that are stored as BLOBs

Output caching

Office SharePoint Server 2007 uses output caching technology native to ASP.NET 2.0 to manage when and how page content is served. When output caching is used correctly, it can significantly improve the throughput and user response time.

Each Web server uses the page output cache to store rendered output of all controls on a given page, and then store several different variations of this pre-rendered page. While a page is cached by the output cache, later requests for that page by the users who have similar permissions are served from the output cache without executing the code or control that created it for the specified duration of the cache. The amount of time required to provide the page to the end user is thus limited to the time required by the Web server to retrieve the page from memory. The page output cache can improve server performance because it reduces server control activity and calls to the database.

If a site is enabled with ASP.NET, the HTML markup generated at run time by each Web page is cached by the ASP.NET output cache, based on the specified cache profile. On a heavily accessed Web site, caching frequently accessed pages for even a minute at a time can result in significant throughput gains.

Note:

Output caching can only be used on a site or site collection if the Office SharePoint Server Publishing Infrastructure feature is activated for the site collection and the Office SharePoint Server Publishing feature is activated for the site. You enable and configure output caching for the site collection by clicking Site collection output cache on the Site Settings page for the site collection, and by clicking Site output cache on the Site Settings page for sites. If the Office SharePoint Server Publishing Infrastructure feature has not been activated for the site collection and the Office SharePoint Server Publishing feature has not been activated for the site, the Site collection output cache and Site output cache links do not appear on the Site Settings pages, and you cannot enable or configure output caching.

Output caching considerations

Before you decide to use output caching to improve the performance of page and page-item rendering, consider the benefits and limitations of an output caching implementation.

Benefits include the following:

Output caching is ideal for Web sites that do not require content update every minute. In this environment, the cached output can be shown to the different users without accessing the database or rerunning the code or controls that created the HTML markup of the Web page.

Output caching can be used for anonymous and authenticated users. However, it is most effective when access is anonymous. Therefore, enable anonymous user access when it is appropriate and workable for part of the Web site or for the whole site.

Limitations include the following:

Output caching uses additional memory to cache the HTML markup for each cached page. Be sure to install enough physical memory to avoid system paging or other memory problems.

When used with two or more Web servers, output caching might affect consistency. You can configure a cache profile not to check for updates for each request and, for example, configure the profile to ignore changes to the version of the Web page in the output cache until 60 seconds after the original page is updated. If you have two Web servers in your topology, and depending on the load balancer used to route the user's request, a reader might see inconsistent content if the page is rendered by one server and then a later request is routed to a second server within that 60-second window. If checking for changes is enabled in the cache profile, it will reduce the effectiveness of the output caching.

If output caching is enabled for users who have write permission for a site collection, these users may not see the most up-to-date data on the Web pages in that site collection until the output-cached pages have expired. Typically, this does not directly affect the content on a Web page that the user is currently changing or viewing. However, it can affect roll-up data from a list or a library. For example, this can affect data presented from a document library Web Part. Therefore, if you want to be sure that users who have write permissions can view all current information, enable output caching for only users who have read-only permissions.

Important:

If you have enabled the Perform ACL Check output cache profile on a site collection that has more than 10,000 unique Access Control Lists (ACLs), output caching will be disabled for the site collection, and you will receive the following error message:

Attempt to release mutex not owned by caller. (Exception from HRESULT: 0x00000120)

To resolve this issue, download and install the SharePoint Server 2007 Cumulative Update Server Hotfix Package as described in Knowledge Base article 968859 (http://go.microsoft.com/fwlink/?LinkId=156055). After installing the April 2009 cumulative update, output caching will still be disabled under the circumstances described above, but no exception will be generated.

Output caching behavior

You can specify the behavior of output caching at the following levels:

Site collection

Site

Page layout

An administrator of a given farm, site collection, or site can optimize caching behavior for the level at which they have administrative credentials by applying different cache profiles. For example, the home page of your site may be accessed most often. Therefore, you can use a unique page layout for the home page. In this manner, you can apply a special cache profile to that unique page layout and override the caching behavior of the whole site collection. By contrast, you can configure the cache profile of the page layout with longer cache duration. This enables you to optimize timeliness of data for the home page where you can afford the trade-off of performance to timeliness. For the other pages in the system, you can use a different cache profile with a shorter cache duration.

Search result caching

In an environment that uses user authentication, you should never cache search results. Doing so can disclose sensitive information to unauthorized users. A search query filters its result set to show only information available to the current user. However, when you cache search results, the code which filters the result set is bypassed. Therefore, unauthorized users can possibly view results to which they should not have access. In an anonymous environment, by contrast, this is not a problem because all search results are the result of unauthenticated requests.

If you have output caching enabled on the site collection, you can disable the search result page layout by performing the following procedure.

Disable search results page layout

On the top-level site of the site collection, on the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

On the Site Settings page, in the Site Collection Administration section, click Site collection output cache.

On the Site Collection Output Cache Settings page, check the Page Layouts can use a different page output cache profile check box, and then click OK.

On the Site Settings page, in the Galleries section, click Master pages and page layouts.

On the Master Page Gallery page, point to SearchResults.aspx, click the arrow that appears, click Edit Properties on the menu that appears, and then click OK in the dialog box that appears.

On the Master Page Gallery: SearchResults page, in the Authenticated Cache Profile list, click Disabled, and then click OK.

On the Master Page Gallery page, point to SearchResults.aspx, click the arrow that appears, and then click Check In on the menu that appears.

On the Check In page, select Major version (publish), and then click OK. Search results that use that particular page layout are no longer cached.

ASP.NET private byte limit

If output caching is enabled, you might want to extend the default ASP.NET 2.0 limit on private bytes. This limit instructs ASP.NET when flushing of its output cache should occur. Premature flushing will cause an unnecessary decrease in performance. For more information, see cache Element for caching (ASP.NET Settings Schema) (http://go.microsoft.com/fwlink/?LinkID=78934&clcid=0x409).

Cached page versions

Certain Web pages might show slightly different versions based on the users or other business logic. You can extend output caching by using the supported programmable API to accommodate the requirement to cache the items differently. For more information, see How to: Extend Caching by Using the VaryByCustom Event Handler (http://go.microsoft.com/fwlink/?LinkID=78935&clcid=0x409).

Output caching and the Content Query Web Part RSS feeds

The Content Query Web Part offers the option of providing RSS feeds of the results that it displays. This RSS feed is generated by an .aspx page on the server, which produces the RSS feed XML based on the same results that the Content Query Web Part displays.

Because RSS clients often request an RSS feed from the server periodically, such as every 30 minutes, it is important that the RSS feed generation performs well. Therefore, the RSS feed .aspx page implements output caching. In the source of the .aspx file, you will see the following line:

This means that, by default, the system caches Content Query RSS feeds for five minutes (300 seconds), caches unique versions of the RSS feeds for each different Content Query Web Part, and caches unique versions of the RSS feeds for users who have different permissions and different feed results.

If you want to customize this output caching, you can create your own feed .aspx page that implements the same logic, but has different output cache settings. Then, Content Query Web Parts can reference your custom feed .aspx page instead of the default page.

In addition, you can disable the whole Search Center site to disable output cache if you have other pages in that site that are sensitive with the same potential security issue. To disable the output cache for the Search Center site, perform the following procedure:

Disable the output cache for the Search Center site

On the top-level site of the site collection, on the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

On the Site Settings page, in the Site Collection Administration section, click Site collection output cache.

On the Site Collection Output Cache Settings page, in the Page Output Cache Policy section, check the Publishing sites can use a different page output cache profile check box, and then click OK.

On the top link bar, click the Search tab.

On the home page of the Search Center, on the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

On the Site Settings page for the Search Center site, in the Site Administration section, click Site output cache

On the Publishing Site Output Cache Settings page, in the Authenticated Cache Profile section, select the Inherit the profile “Disabled” option button.

You can optionally check the Apply these settings to all sub-sites check box if you want to disable the authenticated output cache for all sub-sites.

Object caching

Office SharePoint Server 2007 supports caching of certain page items, such as navigation data and data accessed through cross-list queries. Caching page items reduces the requirement to retrieve field data from the database every time a page is rendered. The caching system also caches complete field data for a page, excluding data for any Web Part controls on the page.

Object cache tuning

The size of the object caching is set at 100 MB per site collection by default. However, you can edit this setting for each site collection to fit the characteristics of the Web site. You can use a set of performance counters to tune the size of the object cache. The name of the performance counter object is SharePoint Publishing Cache Object. Based on the cache hit ratio and the change in object discard counters, you can set the object cache size accordingly. Consider the following items when you are setting this limit:

Start with a low value (for example, 200 MB) and monitor the cache hit ratio and object discard counter. A hit ratio greater than 90% and a low object discard rate are generally good signs that the current size is satisfactory. However, you should also measure user response time for key operations to adjust this setting.

If you set the size too large, you might waste valuable memory for the other caches, such as the ASP.NET output cache if it is used. Certain Web Parts, such as the Content Query Web Part, stores their XSLT stylesheets in the output cache. If the object cache size is set too large, ASP.NET might flush output cache memory to make room for it. CPU usage might increase after the flushing. This is especially important for a system that is running on a 32-bit operating system because each worker process is limited to 2 GB application memory space. If you set the object cache size limit too large, the IIS worker process (w3wp) can run out of memory.

Cross-list query caching

The object cache is also used to cache items that are retrieved as part of cross-list queries. These queries aggregate items from various lists and sites in your site collection. The most common usage of these queries is in the Content Query Web Part. Each use of the cross-list query requires a roundtrip to the database server. By using the object cache, you can greatly reduce the number of round trips required to serve cross-list queries. This improves the performance of features such as the Content Query Web Part that present cross-list query results.

Checking for updates

You can configure the cross-list query cache to check for updates and conditionally refresh the cache in the following two ways:

By checking for changes that were made in the site collection. If no changes were made, the cached results are used.

By waiting for some time, during which the cached results will be used, and after which a query is issued to refresh the cache.

The first setting is useful if there are frequent changes to content in the site collection that the cross-list query displays and it is important that the query displays the latest information. An example of this case is a divisional intranet portal site that displays a cross-list query of the latest documents in the site. In this site, many users are contributors, and it may be important to see the latest documents that users have published.

The second setting is useful if there are not frequent changes to the content in the site collection and it is less important that the cross-list query displays up-to-date information. An example of this case is a public Internet site that displays a cross-list query of the latest article pages that have been published in the site. In this site, most users are anonymous users, or are authenticated users who have read-only permissions. In this case, a few minutes delay of the latest articles is not important.

You can configure the cross-list query cache by using the following procedure.

Configure the cross-list query cache

On the home page of the site, on the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

On the Site Settings page, in the Site Collection Administration section, click Site collection object cache.

In the Cross List Query Cache Changes section, select the appropriate option button, depending on how you want the cross-list query cache to update. If you select the Use the cached result of a cross list query for this many seconds option, type a value in the text box that represents the number of seconds the cache will wait before it refreshes.

Click OK to save your changes.

Number of items to retrieve

The Cross-List Query Results Multiplier setting controls the number of items that are retrieved and cached. Because cross-list queries can retrieve items for various users who have different permissions, it is important to retrieve enough items from the query so that all users see the correct items. To ensure that all users see the correct items in the query results after security trimming, the cross-list query cache must retrieve more results than originally requested. This setting requires an integer that specifies the multiple of the number of items that the cross-list query cache should retrieve.

Setting the multiplier to a larger value retrieves more items and consumes more memory. A larger value is appropriate in a Web site where many users have unique permissions on different lists and items.

Setting the multiplier to a smaller value retrieves fewer items and consumes less memory. A smaller value is appropriate in a Web site where users have the same security, such as anonymous users on an Internet site.

Configure the cross-list query results multiplier

On the home page of the site, on the Site Actions menu, point to Site Settings, and then click Modify All Site Settings.

On the Site Settings page, in the Site Collection Administration section, click Site collection object cache.

In the Cross-list query multiplier box, type a number to specify the multiple of items that the cross-list query retrieves.

Click OK to save your changes.

Disk-based caching for BLOBs

Disk-based caching controls caching for binary large objects (BLOBs) — for example, image, sound, video files, and code fragments. Disk-based caching reduces database round trips that are required to access the BLOBs. When you use disk-based caching for BLOBs, the BLOBs are retrieved from the database on the first request from each Web server and stored in a folder on the Web server file system for the expiration time required by the single item. Subsequent requests are served from the disk-based cache and trimmed based on security.

Use the BLOB cache to minimize database calls when the content database contains a lots of static content (.css files, XML files, HTML files, or attachments in article pages).

Note:

Using the BLOB cache can affect disk I/O on Web servers in the farm.

The following list describes the settings that you can configure for disk-based caching.

max-age specifies the maximum time in seconds that the client browser caches BLOBs that are downloaded to the client computer. If the downloaded items have not expired since the last download, the same items are not re-requested until the cache expires. By default, the max-age attribute is set to 86400 seconds (that is, 24 hours), but you can set it to a time period of zero or larger up to 31536000 seconds (that is, 365 days).

Path specifies in the form of a regular expression which files are cached, based on the file name extension. By default, the following extensions are included: gif, jpg, png, css, and js. If you have special file types that your Web pages reference, you must add the extensions to the cache.

changeCheckInterval specifies the time in seconds that the disk-based caching is updated on the Web server. By default, the changeCheckInterval attribute is set to 5 seconds. However, this value can be increased. The larger this value, the longer the time that content in the disk-based cache is not updated on the Web server.

Location specifies the location where the files are cached on the Web server. The value of this attribute must point to a valid drive letter and a valid directory or folder. The hard disk must also have sufficient free space to accommodate the specified cache size.

maxSize specifies the maximum size of the cache in bytes. After this value is reached, the cache is flushed until the size of the cache on disk is 20% less than the value specified in maxSize attribute. By default, the maxSize attribute is set to 10737418240 bytes (that is, 10 GB). The minimum value allowed is 1073741824 bytes (that is, 1 GB).

Enabled specifies whether disk-based caching is enabled or not. The Enabled attribute accepts any value that has a valid Boolean representative. The default value of this attribute is True.

policyCheckInterval specifies the time elapsed in seconds before disk-based cache settings are parsed again by the Web server. By default, the policyCheckInterval attribute is set to 60 seconds. However, you can set it to a larger value.

Disk-based caching applies only to items in a document library. If you store resources outside a document library, such as a folder underneath a site, the items are not managed by the disk-based cache even if you enable disk-based caching for the Web application. This is important if you want to control the max-age setting of the BLOB resources downloaded to the client browser. By default, the max-age of all items that are stored in Office SharePoint Server is set to zero.