Digging Deeper into the 2010 Caching Options: Part 1

There is nothing complicated about caching in SharePoint 2010. TechNet provides a decent overview of the three options available that will improve the overall performance of how the web pages load in the browser. If you haven’t read the article on Cache Settings Operations, I would definitely encourage you to do so. SharePoint stores most of the content it needs to serve up in the content database, so any time we can save a trip, we are helping the performance of our application.

So we will be examining the three types: BLOB cache, page output, and object cache. Page output and object cache require that you activate the ‘SharePoint Server Publishing’ feature located in the site features of your web site, so these will not be available to you if you are using SharePoint Foundation. BLOB caching, on the other hand, is available in the server product and will be where we start off.

 

BLOB Caching is a disk based cache. You configure it in the web.config file of the web site, which means that you will need to go to each WFE to set it up. Your web.config file is typically located at Local Disk:\inetpub\wwwroot\wss\VirtualDirectories\SiteFolder. Before making any changes to your web.config, you will need to back it up. It can be quite difficult to repair this file if you happen to make a mistake.

Inside the web.config file, find the following line:

<BlobCache location=”C:\BlobCache\14″ path=”\.(gif|jpg|jpeg|jpe|jfif|bmp|dib|tif|tiff|ico|png|wdp|hdp|css|js|asf|avi|flv|m4v|mov|mp3|mp4|mpeg|mpg|rm|rmvb|wma|wmv)$” maxSize=”10″ enabled=”false” />

If you are familiar with BlobCache from 2007, it works the same way. One nice thing about 2010, is that you get a very long list of file types that default to Blob cache as opposed to the previous version. I am going to save much of the explanation of Blob caching for the article written on TechNet: Plan for caching and performance. Once you have it set up, upload a few photos to a picture library and will see them populate the blob location.

In the root of your blob location, you will find a series of folders. Each of these folders represents the various web applications on your WFE. If you’re a little confused on which folder maps to which web site, simply check the Sites in your IIS Manager. The folder name is the Site ID.

 

In each of the sub folders is an additional folder and a file named currentcache.bin. If you rename the currentcache.bin file to a text file and open it up, you will see that it is the path referencing the cryptic named folder associated with it. Inside the cryptic folder, you will start to see the site structure of some of your content and additional bin files: change.bin, dump.bin, fulshcount.bin, filestodelete.bin, inprogressdump.bin, and oldcachefolders.bin.

change.bin: This file contains serialized change tokens (SPChangeToken) for objects being cached in the local file system.  These tokens allow the BlobCache maintenance thread to query the content source(s) and subsequently update the contents of the BLOB cache with any items that are identified as having changed since the last maintenance sweep.

dump.bin: This file contains a serialized copy of the BlobCache’s cache dictionary.  The dictionary maintains information for all objects being tracked and maintained by the BlobCache object; each key/value pair in the dictionary consists of a local file path (key) and its associated BlobCacheEntry (value).

flushcount.bin: This file contains nothing more than the serialized value of the cacheFlushCount for the BlobCache object.  Practically speaking, this value allows a BlobCache to determine if a flush has been requested while it was shutdown.

 

One of the changes from MOSS 2007 and SP2010, is that the files use to be stored with a .cache extension. They now have their original description. Another change that I noticed is that the ‘Disk Based Cached Reset’ is no longer available, but you are able to flush the object cache.

 

One thing I was expecting is that if I went into the file system and deleted the files from the cache directly, that they would be populated on the next request. This was not the case. Once deleted, the files were still visible on the site. I was thinking that SharePoint was now going back to the content database to get these file, but I was wrong. I started up an instance of Fiddler to see if I could find these requests. These files are now being rendered by the cache of my web browser. When I deleted my temporary files, I found that the image no longer rendered. I tried several different ways to repair my site. I used the ‘Object Cache Flush’ to see if it had any influence on the BLOB cache. It did not fix my issue. In fact, I had to go as far as deleting all of the .bin files and toggle the web.config file to get the image to render again with blob cache enabled.

 

In MOSS 2007, we had a property called max-age. It allowed you to specify how long cached content would be valid in you blob location. This was measured in seconds, so I attempted to enter a value of “60” to force my image to go back to the database. I wanted to make sure there weren’t any leftover references, so I once again deleted the .bin files, my image and toggled my web.config. The image was recreated in the blob location with a time stamp of 2:11 PM. I expected to wait a few minutes and refresh the page and get a new item in the blob storage location. This was not the case.

I did find some interesting behavior while playing around with the image properties. I found that if you have an image stored in the blob location and then change one of the properties, the image was updated leading me to believe that the max-age no longer works, but the SharePoint team has obviously set flags to check if the file has any changes and then refreshes the file accordingly. You may also notice that your image may not render until your browser cache is cleared.

In my previous post, I mentioned the HTTPModules that get included in the HTTP request. While researching BLOB cache a little deeper, I found a very informative post by Sean McDonough, that states that BLOB cache is implemented by way of Microsoft.SharePoint.Publishing. This class is loaded in the PublishingHTTPModule. This means that while Blob cache does not require that publishing features be activated, it will not work in SharePoint Foundation. I went back to review the list of IIS modules to see where the PublishHTTPModule fell into the ordered list view. I have it highlighted in blue below.

 

In the next post, we will take a look at the output cache.