Part 5: Object caching

The object cache is used internally to optimize page rendering by storing properties of sites, lists, libraries, page layouts and pages in memory on the web front-end server. Also results of cross-list queries are stored on the web server when object cache is enabled.

As with the other caches, the object cache reduces the amount of traffic between the web front-ends and the content database in order to render the pages faster.

The object cache also caches the results of cross-list queries. This is especially beneficial when a page needs data coming from multiple SPWebs: in that case the query must be executed for each web.

To be able to use the object cache, you must have the Publishing features activated on your site collection and on your sites.

There are also a number of out of the box artifacts that use the object cache mechanism by design.

• The Cross-list Query calls the site (SPWeb object) and searchs for items in one or more lists. The results of the query are cached. Next time the same query is executed, the items will be served from the cache, which of course improves the performance of the query. You can use cross-list query caching across sites in a site collection. Additionally, the cache configuration includes enough metadata to dynamically trim for security each time the query is executed.
• The Content Query Web Part uses cross-list query caching to improve its performance.
• The PortalSiteMapProvider is a part of the SharePoint Publishing API and is typically used by navigation controls. All results returned by methods of the PortalSiteMapProvider are automatically stored in the object cache.

When a control queries the object cache for data and the data is not yet in the cache, the cache will need to query the content database but not with the permissions of the requesting user; and it will make the query twice: once as a user called the PortalSuperUserAccount and once as PortalSuperReaderAccount. The results for the Super User query will include draft items while the results for the Super Reader query will include only published items. The cache will then check the permissions of the user that initiated the request and will only return the appropriate results to that user. Thanks to these special accounts, the cache only has to store results for two types of users. This decreases the cache’s memory footprint.

For most deployments with less than 50 site collections, the object cache should have a relative small memory footprint. It is a good rule of thumb to allocate 500KB RAM per site collection.

Remarks:

• SharePoint always returns the checked-out version for items that a user has checked out.

Configuring the Object Cache

Before configuring the object cache at site collection level, you first have to configure the Portal Super accounts. If you don’t configure these accounts, the object cache will not function properly and you will frequently get the following error in the event log:

In a presentation about performance of Shai Petel I read that by default super user is the site System Account and super reader is Local Service. Problem with these defaults are:

• If the user uses the super user account to log into the site and ever checked out a file for example (some use the SharePoint System Account… ), the cache will store the checked out version and not the published version. This will make the cache double check and reload those items when ever a user try to run a query that uses this cache, thus eliminating the benefit of the object cache.
• For super reader, the Local Service does not resolve correctly in claims authentication application. This means, it will not be able to run the super reader query. Features that explicitly try to use the object cache, in this situation, will receive “access denied” to all users regardless to the current user permissions. Such features OOB are: publishing infrastructure, CQWP,  meta data navigation or navigation.

You first create the accounts in Active Directory. Then you give full control rights to the PortalSuperUserAccount and read rights to thePortalSuperReaderAccount. Then you add these accounts to the properties of the web application. This is generally done using PowerShell:

$wa = Get-SPWebApplication -Identity "<WebApplication>"
$wa.Properties["portalsuperuseraccount"] = "<SuperUser>"
$wa.Properties["portalsuperreaderaccount"] = "<SuperReader>"
$wa.Update()

But you can also configure these accounts in the Central Administration.

Once that’s done, you can configure object caching. In the site collection settings section you can find a link Site collection object cache. There you can configure a number of options like:

• Max size
• Flushing
• Cache Invalidation
• Multiplier

Max size defines the size of the object cache. When the object cache becomes larger than this value, least popular entries (based on hit count) will be trimmed from the cache. Specifying a larger size can therefore enhance the performance for large sites at the cost of memory on the WFEs.

A multiplier can be used to retrieve more results than requested. This is to ensure that all clients requesting data can be served correctly by the result set in the cache, even if they have a different permission set. The multiplier can have a value that ranges from 1 to 10.

Flush the object cache

If you need to flush the cache you can navigate to the page and check the Flushing checkbox. When you click the OK button the object cache will be flushed on all the web front-end servers.

Cache invalidation

Object cache invalidation is configurable and behaves similarly to the output cache: the cache can be configured to check for site changes on every request or to check for updates periodically. Checking for site changes on each request carries a small performance penalty because each request must access SQL Server to determine if there have been changes; using a periodic check results in better overall performance.

The object cache is not completely invalidated by a site change.

The cache can either check for changes on each request, or it can check for changes periodically when a certain amount of time has elapsed. When an object is expired, it is removed from the cache and only added again when requested.