Wednesday, February 23, 2011

BLOB Cache

BLOB Cache or Binary Large Objects caches stores frequently used large objects such as images, audio's etc that are accessed every time a site loads.

It's a disk based cache

First time a BLOB file is requested, it is fetched from the DB and stored in the BLOB cache.  Thereafter, it is accessed from the cache only.  Thereby minimizing the traffic.

Flushing a BLOB Cache: Flushing of the BLOB cache can be done for a web application in cases such as restoring the content DB where in the content DB and the cache go out of sync.

Flushing the BLOB cache will have an effect on the entire web application that include all the site collections present in the wep app.

It can be done only thru powershell or object model

Procedure is provided in the link referenced below.

To enable blob caching you need to modify only one line in the web.config file:
<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false"/>


Just change the false in the enabled attribute to true and update the location attribute to point to a location where sufficient disk space is available. For best performance ensure to set the maxSize attribute to a value that is at least as big as all binary objects in your Web Application.

You can control which file types are cached by modifying the file extension list in the path attribute.

Responsible for the processing of the disk caching logic is the following entry in HttpModules section of the web.config file:
<add name="PublishingHttpModule" type="Microsoft.SharePoint.Publishing.PublishingHttpModule, Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />


This HttpModule implements the required logic that decides whether a file can be served from the disk cache or if it has to be retrieved from the backend database.
Important to know is that even that this HttpModule is located in the WCM Publishing namespace you its functionality is not limited to publishing sites. Other site collection types like team sites can also use this functionality.

Limitations of Blob Caching

1) Blob caching does not support web gardening
One major limitation is that blob caching should not be used with web gardening. The reason is that each process requires exclusive access to it's instance of the blob cache. That means that only one worker process can access a single instance of the blob cache. Web Gardening means that multiple worker processes serve content for the same application pool. Only the first process of a web garden will then benefit from blob caching which would mean that web gardening would cause negative impact on the overall performance.

2) Blob caching cannot be used with host named site collections
The blob caching engine uses the server relative path to decide if an item in the cache belongs to a URL or not. With host named site collections an additional criteria come into play: the "host" http header. The blob cache engine on the other hand is not aware about host named site collections. That means if you have two site collections with items that have the same server relative URL (e.g. items in the style library) but are different the item that was first hit gets cached and served for all other host named site collections as well.

3) A cached item is only available in one frontend server
The blob cache is a per server cache. That means if an item has been cached on server 1 and the next request for the same item hits server 2 then the item has to downloaded again to the second frontend server. That means the load on a SQL backend server can be higher in the startup phase if multiple frontend servers exist as the same item might have to be downloaded multiple times to the different frontend servers.

Courtesy/Reference/Credits:

No comments:

Post a Comment