A really nice new feature coming with MOSS 2007 is blob caching. A similar feature existed in MCMS 2002 was a predecessor of the WCM layer in MOSS 2007.
Blob caching allows caching of binary objects like images, style sheets and documents on the MOSS front end server machine which heavily reduces the traffic to the SQL backend server as each file has to be downloaded only once to the blob cache per frontend server.
The benefit is that although the items are now retrieved from the MOSS 2007 frontend server the same security and versioning capabilities exist as if the file would only live in the SQL backend database. The blob cache mechanism also ensures that an item in the cache is invalided as soon as the file changes in the backend database. So that is different from other file caches like proxy servers and browser caches.
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.
