Controlling the BLOB

The third part of the caching trilogy covers the BLOB cache, or binary large object cache. In a typical site there are many references to CSS files and images. MOSS caches these objects to prevent multiple trips to the database for these resources. MOSS caches these resources on the Web-front end servers in the file system. This type of caching is not enabled by default.

To enable BLOB caching change the line in the Web.config file for the blobcache to true. You can set the maximum size for the cache in this line as well. The default is 10 GB. In the path attribute you can determine the file extensions that will be cached in this type of caching. You may want to add such file extensions as .swf for Flash movies, if your site utilizes them. NOTE: this caching only works on items that are in document libraries and lists. If you place files in the site but not in a library or list, the caching will not cache the file.

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="True"/>

You can also set the maxAge to the number of seconds that you want the client to retain the object in its cache. This allows the client to use its copy of the resource and not re-request the URL for the resource until the timeout has expired.

With these three types of caching your Internet facing MOSS site can efficiently serve up files to many users.

Additional resources for caching:
Microsoft Enterprise Content Management (ECM) Team Blog
Custom Caching Overview

When a Cache is Not a Cache

The first problem area I had with our project was when we made the Internet-facing site live. We set up output caching and BLOB caching to cache pretty much all of the site. We also setup the Object cache. We figured we had our bases covered because we tried these things on our development site and they increased page load time significantly.

The site went live and it was doing well for most of the morning when 11 o'clock hit and we now had 3 time zones worth of people hitting the site. We suddenly noticed that the processor was getting pegged at 100% and that the amount of memory used was increasing quite quickly.

After spending a week looking at the performance monitor for various counters and checking Microsoft documentation, we had finally figured out that some of the memory leak was due to not cleaning up SPRequest objects. We cleaned up all of our custom code and this improved the site marginally. We also began tweaking the output cache to find a good balance and settled on 4 hours for pages to be cached. The BLOB cache works wonderfully, it caches images, and other Binary Large Objects. It is awesome to see whole pages load without images filtering in one at a time.

The site was still not running quite right and we had noticed on the object cache counter that objects were being thrown out of the cache as soon as they were put in. I began monitoring the SharePoint logs and found that pages were being invalidated and thrown out of the cache. So this led to a call to Microsoft. After the same questions and sending them an SPSReports CAB file, they came back saying that the object cache does not cache custom code objects. This didn't fare well as almost every page of our site has custom code on it. After looking over the options and Microsoft telling me that there was no expected date for a fix, we decided to monitor the site some more and noticed that the page output was still being cached, so the object caching not storing our code was only going to be a problem for the first person to hit that page. We decided that this was acceptable performance for the site.

In the next few blog posts I will explain the various types of caching and how they can help your MOSS site's performance and scalability (especially if an Internet-facing site).