Home > Performance and Tuning > Digging Deeper into the 2010 Caching Options: Part 1

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.

About these ads
  1. Sean McDonough
    April 5, 2010 at 8:30 pm

    Nice article, Shannon! I enjoyed reading it.

    In your post, you mentioned seeing some behavior that led you to believe that the BLOB cache in SP2010 behaves differently than it did in 2007. I haven’t explicitly played with the BLOB cache in 2010 yet, but I suspect that it probably continues to work similarly to how it did in 2007. That said, I wanted to hazard a guess at (potentially) explaining some of the behavior you were seeing based on how things work with MOSS 2007.

    With 2007, the max-age attribute on the BlobCache element specifies the maximum duration that items are cached *on the client side* via client cacheability headers that are sent to the browser. I suspect this is still the case with 2010. Max-age is not used to specify the duration that items are saved or remain valid on the server-side.

    As you’ve observed, SharePoint will update objects in the server-side BLOB cache whenever they are changed. This is carried out through a background sweeper thread that semi-regularly does a change token comparison between objects in the BLOB cache and their backing items in the content database. Deleting objects out of the server-side BLOB cache folder will break requests for those objects until (a) the BLOB cache is flushed, or (b) the object changes in the content database (thus forcing a re-fetch).

    So, max-age only plays a role in how and when a client (browser) requests objects from the SharePoint site — not in how often or frequently objects are requested by the PublishingHttpModule (from the content database) for insertion into the server-side caching folder. The two operations follow two different paths.

    For what it’s worth!

    • April 5, 2010 at 8:40 pm

      Sean,

      Thanks for your comments. That does clear up the max-age question that I did have. I have confirmed that the logic still resides in the PublishingHttpModule, so your article on 2007 seems to still be right on the money.

      Shannon

  2. January 24, 2012 at 3:39 am

    hello,

    As I read in this article, with sharepoint foundation 2010, i can only use the blobcache optimisation.
    In my webconfig of my wsf 2010, I have not the blobcache section.
    Are you sure I can use it ? do you know if there is somewhere article describing optimisation of foundation 2010.
    Thank’s

    • January 24, 2012 at 2:50 pm

      The BlobCache feature is tied to the publishing infrastructure and is not available in Foundation. :(

  1. May 9, 2012 at 12:27 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 30 other followers

%d bloggers like this: