Digging Deeper into the 2010 Caching Options: Part 2

As I mentioned in my previous post, the object and output cache options require you activate the ‘SharePoint Publishing Feature’ or as I like to call it, the Cha-Ching Feature, as it is normally where Microsoft puts its entire set cool features (i.e. caching, navigation, etc.).

So now that we have experimented a little with the BLOB cache, let’s move on to the output cache. Once you active the appropriate feature(s), you will find your caching options under the Site Administration and Site Collection Administration option of your SharePoint’s setting page.

The output cache is responsible for storing the output of a page. It has the capability to store various versions of the same page based off of parameters. An example of this would be caching pages based off of local area like zip codes. Like the other caching options, output cache can really improve the overall performance of your SharePoint implementation by eliminating the most expensive part of the request: the content database. In a previous post, I outlined the HTTP request. If you examine the steps, you will notice that having output cache enabled cuts out the majority of the hard work help to ensure that the end user is getting what they need without any latency. All though output cache can really help in all areas, it is extremely powerful when it comes to publishing pages with anonymous access enabled. In the world of caching, you don’t want to server your content contributors cached pages, since you want them to be able to review the latest and greatest. When it comes to anonymous users, it’s an entirely different story. Output cache stores the pages in RAM, so after the page is requested the first time, it is ready to rock and roll. The short story is… cache for anonymous and not for publishers. Show how do you separate the two? Caching profiles help you do just that, and in SharePoint 2010, they have improved quite a bit.

Once you click the ‘Output Cache Settings’ link, you will have the option to select the ‘Enable output cache’ checkbox. Under this you will notice the Default Page Output Cache Profile.

A cache profile specifies how long items should be held in the cache. It also describes to the caching system how to determine whether a cached page element is in fact valid for other requests for the same element from different users.

You can specify different cache profiles to use for anonymous and authenticated users. This optimizes the use of the cache based on the authentication methods allowed on the site.

Page output cache profiles specifically affect portal publishing pages.

So by default, you have four caching profiles to choose from: Disabled, Public Internet, Extranet, and Intranet.

You also have the opportunity to specify a different caching policy for page layout designers and administrators and also specify whether or not you wish to collect Debug Cache Information. The debug cache information shows up in the source of your web page and will let you know which caching profile is currently enabled and when the information was saved.

Now we are going to take a look at a caching profile so that you can see how these guys work. We will focus on the Public Internet profile. Here you will see various properties that you can set. TechNet has an article on how to set many of the cache settings, but doesn’t go into caching profiles, so I will discuss these a bit.

Perform ACL Check – When this is set to ‘yes’, it will ensure that all of the items in the cache are properly trimmed for security by checking the access control list of the items. That sounds like something you might want to do all of the time, but remember this is an anonymous profile, and these visitor have limited to no rights.

Duration – This is how long the item will be cached for in seconds. The default setting is 180, so it’s 3 minutes.

Check for Changes – If this is set to ‘Yes’, SharePoint will check for changes in the page prior to rendering. So if you have this set, the duration doesn’t really add much value. If you want to keep your content for a specific amount of time, set this to ‘No’ and use the duration to its fullest potential.

Now we get to the Vary by parameters. These allow you to store multiple versions of the same page based off of specific values. You may have one cache setting for one HTTP Header versus another or based off of a Query String Parameter. Query Strings are represented in the URL by way of values after the ‘?’.

The Cacheability parameter specifies the devices that the object can be cached on. These are an enumerations are from HTTPCacheability (ASP.NET 2.0) and has six values, four that map directly to a Cache-Control HTTP header settings and two special values called HttpCacheability.ServerAndPrivate and HttpCacheability.ServerAndNoCache. ServerAndPrivate, the default setting here, allows a response to be cached only on the origin server and the requesting client. ServerAndNoCache means only the origin server.

Safe for Authenticated Use specifies whether or not an administrator can use this policy for authenticated users.

Allow writers to view cached content does exactly what it says. I don’t know of a good reason to use this one, but someone must have one, J

Ok, so that’s the run down on the caching profiles. Mix that with the output caching and you have a pretty powerful tool at your disposal.

Most of the caching options are only available to the Site Collection Administrator, but the Site Administrator does get the Site Output Cache option, which simply allows for overriding the Site Collection cache profile settings.

In my research for really trying to understand all of the caching mechanisms, I found a post called Measuring ASP.NET and SharePoint output cache. It’s short and sweet, so I will be applying these concepts to my virtual farm and make it the topic of my next post.