Optimizing BLOB caching for WAN environments (SharePoint Server 2010)

 

Applies to: SharePoint Server 2010

This article describes how to use BLOB caching in Microsoft SharePoint 2010 Products for WAN environments.

Caching is typically addressed as a way to improve throughput in the rendering pipeline—from the time that a request is received at the server until the time that a response begins to stream back to the client computer. Although this is an important aspect of your overall site performance, this section focuses on caching as it relates to the following:

• The role of server configuration on client caching.

• Controlling the size of items that are transmitted over the network from the server to the client.

About BLOB cache

The BLOB cache is a mechanism that is available only with SharePoint Server 2010 publishing features. This makes it an ideal candidate for corporate portal sites that are based on the Collaboration Portal site template and Internet-facing sites that are based on the Publishing Portal site template. The BLOB cache enables you to configure caching directives that are associated with items served from publishing site lists, for example, the Pages library and Site Collection Images. When the browser on the client computer encounters a caching directive, it detects that the item it is retrieving can be saved locally and does not need to be requested again until the caching directive expires. In a geographically distributed environment, this is important because it reduces the number of items requested and sent over the network.

When the BLOB cache in SharePoint Server 2010 is turned on, two different things occur. First, every time that a cacheable item is requested, SharePoint Server 2010 searches the hard disk drive of the Web server that received the request to see whether a copy exists locally. If it does, the file is streamed directly from the local disk to the user. If it is not on the local disk, a copy of the item is made from the SQL database where it is stored, and then the item is sent to the user making the request. Afterward, all requests for the item will be served directly from the Web server until the item's cacheability value indicates that it has expired. This results in better performance in the server farm by reducing contention on the database server.

The other thing turning on BLOB cache does is append a cacheability header to the item when the item is sent to the client. This header instructs the browser how long the item should be cached. For example, if a picture had a cacheability value of three days, the browser uses the copy of the image it has in its local cache if the picture is requested again within the next three days; it does not request it from the server again.

Using Fiddler to gather data about BLOB cache

When testing your site to see what items are cached and how items are being cached, you can use a free debugging application called Fiddler (http://www.fiddlertool.com). The following screen shot shows a Fiddler capture on a simple SharePoint site that is used for publishing. The site was created by using the default Collaboration Portal site template. Some additional text content was added to the page, and several images were added to the master page.

There are several important pieces of information contained in the Fiddler application.

• The # column on the left indicates that there were a total of 44 HTTP requests made from the browser to the server to render the page.

• The Result column shows the HTTP result code that was returned from the request for the item; a 200 result means the item was successfully retrieved.

• The URL column indicates what specific item was being requested.

• The Body column indicates the size of each item.

• The Caching column shows the caching directive that was associated with each item. The data in the Caching column shows that several items have a caching directive associated with them; that is, they have a max-age attribute that is greater than 0. Caching directives are expressed in seconds. This mean that for the page illustrated several items are configured to be cached for 365 days (60 seconds in a minute, 60 minutes in an hour, 24 hours in a day = 60x60x24 = 86,400x365 = 31,536,000).

Notice that the items with that cache directive all reside in the _layouts directory. The reason they have this cache setting is because of the way the _layouts/images virtual directory is configured in IIS. When you create a new Web application, SharePoint Server 2010 automatically creates several virtual directories that map to folders on the Web server physical disks. When it creates the _layouts/images virtual directory, it adds a caching directive that applies to the whole directory. The following screen shot shows the configuration for the directory in IIS Manager snap-in.

Because these items all have a non-zero caching directive associated with them, the next time that the page is requested, the browser uses the copy of the item from its local browser cache instead of requesting it from the server again. The following screen shot shows a snapshot of Fiddler when the page is requested a second time.

As the Fiddler data shows, the number of items requested has reduced significantly—from 44 to 11. An important point to note is that the number of requests made may vary depending on how the page is requested. If you use the Refresh button in the browser, all of the items will likely be requested again, whether a local cached version of the item exists or not. Conversely, if the page is requested by going to it by using a link or shortcut, only the uncached items are requested.

The other thing shown in the Fiddler data is that the browser is making a request to the server for the other images on the master page that it already has in its local cache; the 304 response code indicates this. It means that the browser has made a conditional request for an item. The 304 response means that the version on the server has not been modified from the version on the client so that it does not have to be downloaded again. Even though the file is not downloaded over the network, it still has generated a roundtrip to the server to determine whether the local copy is current. In a geographically dispersed environment, server round trips are costly. So, the goal is to reduce these as much as possible. This can be achieved by adding a non-zero caching directive to each of the remaining items (other than the page, which is always returned by the server). The BLOB cache feature adds this caching directive.

Configuring BLOB cache by using Web.config

You configure the BLOB cache by using the Web.config file for the Web application in which the cache will be used. Open the Web.config file in a text editor such as Notepad and search for the BlobCache entry. By default it will be:

<BlobCache location="" 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" />

The attributes used in the BlobCache element have the following meanings:

• location    Refers to the location on the Web server hard disk drive where cached items will be stored.

• path   A regex expression of the kinds of files that should be cached.

• maxSize **   **The size, in GB, that the cache can use.

• enabled    Set to true to enable the BLOB cache.

The following additional attribute—not included by default—is necessary to set a caching expiration value on individual items:

• max-age   The time in seconds that items should be cached on the client computer.

By setting the max-age attribute to a non-zero value, cacheable items have a cache expiration value associated with them so that a browser no longer has to download the item, or even verify that it has the most current version. For example, assume that you want to enable caching and allocate up to 100 MB on the Web server to store items. They should expire one time per day, and in addition to the predefined types that are cached, .htc files should be cached also. To support those requirements, specify the following BlobCache attributes:

<BlobCache location="C:\blobcache" path="\.(gif|jpg|png|css|js|htc)$ " maxSize="100" max-age="86400" enabled="true"/>

Note that this change to the Web.config file has to be made on every Web server in the farm. In most cases, the BLOB cache will start to work immediately, but it is safest to use the iisreset command when you implement the changes. The following screen shot shows Fiddler data for the same page request shown previously, only with the BLOB cache enabled as described.

Notice that all of the items in the /SiteCollectionImages library now have an HTTP status code of 200, which indicates that they have been successfully downloaded. In addition, they all now have a Caching directive associated with them that specifies they will not expire for one day (86,400 seconds). If the page is requested again, Fiddler shows that none of the images are requested again; the total number of requests to service that page has therefore gone from 44 down to three, and two of the remaining three requests are merely the NTLM authentication negotiation that occurs between the Web server and client application. The following figure shows Fiddler data when the page is requested again.

Additional considerations when you are using BLOB cache

Additionally, consider the following when you work with the BLOB cache:

• It requires some additional effort to configure because you have to update the Web.config file on each Web server. However, the benefits are worth the effort.

• Survey your site contents and determine whether there are any other file types that should also be served from cache. A good example is .htc files. Because .htc files are used in most publishing sites, you should add that file type to the list of file types being cached.

• The BLOB cache only works on items that are stored in SharePoint libraries; it cannot be used to cache content from other sources.

• Some lists by default do not work for anonymous users. If there are anonymous users who are accessing the site, permissions have to be manually configured for the following lists in order to have items within them cached:

  • Master Page Gallery

  • Style Library

There are two other configuration options to be aware of when you are working with the BLOB cache. The first relates to clearing out the BLOB cache. If the cache has to be cleared out for particular site, browse to that site collection and then click the Site Actions…Site Settings…Modify All Site Settings menu. In the list of Site Collection Administration tasks. click the Site collection object cache link. In the Disk Based Cache Reset section, select the Force this server to reset its disk-based cache check box and then click OK.