Disk-based Caching for Binary Large Objects
Disk-based caching controls caching for binary large objects (BLOBs) such as image, sound, and video files, as well as code fragments. Disk-based caching is extremely fast and eliminates the need for database round trips. BLOBs are retrieved from the database once and stored on the Web client. Further requests are served from the cache and trimmed based on security.
Disk-based caching is disabled by default. To enable and customize the disk-based cache, you must modify the following statement in the web.config file for the SharePoint Web application.
By default, it looks like this: <BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="false" />
In order to improve the performance of your site, the BlobCache should be enabled. <BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" enabled="true" />
<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="false"/>
In the preceding example:
• location is the directory where the cached files will be stored • path specifies in the form of a regular expression which files are cached based on the file extension • maxSize is the maximum allowable size of the disk-based cache in gigabytes • max-age specifies the maximum amount of time in seconds that the client browser caches BLOBs downloaded to the client computer. If the downloaded items have not expired since the last download, the same items are not re-requested when the page is requested. The max-age attribute is set by default to 86400 seconds (that is, 24 hours), but it can be set to a time period of 0 or greater. • enabled is a Boolean that disables or enables the cache.
We can flush the current site collection object cache. To do this, browse to the following location on the web site, Site collection administration -> site collection object cache -> disk based cache reset.
If we have multiple WFEs in the farm, each WFE will maintain its own copy of Disk-based Cache. SharePoint does not have a Web user interface (UI) to flush the disk-based cache on all the servers in a farm and neither is there an option to select a specific WFE.
4.The option provided in the Administration page for flushing the cache is only to the flush the cache on the web front end to which you are currently browsing.
if you would like to flush the complete binary large object (BLOB) caches associated with a specific Web Application on different Web front-end computers in a farm, then you can use the STSADM command to do so.
STSADM -o setproperty -propertyname blobcacheflushcount -propertyvalue 11 -url http://mywebapp:port
After enabling blob cache in web.config, do an IISRESET and browse to the /settings.aspx first, instead of home page (Collaboration portal site).
When we browse to the settings.aspx, it will create the following files change.bin, dump.bin and flushcount.bin (all the files will be 1KB in size).
Browse to the home page now, it will create a folder PUBLISHINGIMAGES, all the images rendered from the database will be stored here and the above bin files will also get updated (we can see the difference in file size).
Every time when a new image file is rendered from the database, the image folder gets a copy of the image. The bin files (index) will get updated with an additional entry for the new file.
Every request from client will check the index file first. It will only check the cache index and not the image folder directly for the image. If the index file does not have an entry for the image, then the request is served from the database. During this time, a copy of the image will be stored in the images folder and the index file also gets updated, so that the next request will not go to the database.
We will not see the image on the client page; we get a broken image ‘X’.
Filename.extension.cache is the file naming format.
Recommendation: We can reset the index file. Site settings -> Site collection object cache -> Check the box for “Force this server to reset its disk based cache”. It will completely delete all the images and reset the bin files back to 1KB, so that next request will go to database and the complete index will get rebuilt.
Workaround: If you do not want to reset the complete index. Find out the missing image and copy just that file to the cache folder, name it as “filename.extension.cache” Refresh the page now; it should pick up the image.
Every time when the web.config initializes, the index file is loaded from the blobcache folder to memory. All new entries will keep getting updated in index file when in memory. IISRESET /stop will flush the updated index file from memory to disc within the blobcache folder. IISRESET /start will load the index file from blobcache folder to memory. As long as the application pool is alive the index file will be getting updated in memory itself.
Index file corruption is possible only when IIS crash or the index file is overwritten with wrong information. When IIS tries to load the index file from blobcache to memory and identifies that it is a corrupted file (not a valid file), it will get completely rebuilt (flush) as fresh file (1KB), all the old entries and images will be lost.
No, this cannot be done because SharePoint maintains the index and the cache files individually on each server.
Web gardening is not supported.
If the requirement is to “centralize” static cached files, then 3rd party content distribution network (CDN) solutions like Akamai need to be used.
What are the limitations of SharePoint and blob caching in a farm environment? a. Blob caching does not work with Web Gardening. b. Blob caching does not synchronize data across WFEs – so we might be seeing different versions of the files for a short duration across different WFE servers.
Ported from http://blogs.msdn.com/b/selvagan/archive/2008/12/11/blobcache-moss.aspx