Karine Bosch’s Blog

On SharePoint

Part 3: BLOB Caching in SharePoint 2010

The first caching technique we will look at is BLOB caching. BLOB stands for Binary Large Object and is typically used to cache files stored in document libraries and asset libraries and therefore stored in the configuration database. These are image files, video material, css files, javascript files, etc.

When a file is requested for the first time, the BLOB cache retrieves the file from the content database and stores it in a local directory on all web front-end servers. At that time there is a small performance penalty because the BLOB cache needs to make another roundtrip to the SQL Server database to fetch permissions and other metadata to serve the file securely from cache on next requests. When another request for a cached file comes in, the BLOB cache returns the file from the local directory on disk from the WFE, avoiding a roundtrip to the SQL Server database. As from that moment you have a performance improvement.

BLOB caching is useful when resources such as JavaScript files, CSS and images are frequently accessed. It is also useful in case of rich media and videos, which are in general rather large files. BLOB caching is not that useful when files are not frequently accessed or change a lot. In that case, the chance that the file is still in the BLOB cache when subsequently requested is too low while getting it from the database and storing it in BLOB cache causes a performance penalty.

How to configure BLOB cache

This cache can be configured on SharePoint web application level. It can only be configured in the web.config; not from within the Central Administration interface.

You can find an element named <blobcache>. It is disabled by default. You can enable the BLOB cache by setting the enabled attribute to true.

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

Besides setting the enabled attribute to true, you can also set a number of other attributes:

  • Location: this contains the path to the local drive where the WFE will store the cached files. SharePoint creates a sub folder with the name based on your IIS site ID.
  • Path: this contains all file extensions that are candidates for caching.
  • maxSize: is  a value in gigabytes that specifies the maximum allowable size of the disk-based cache. This is to keep the BLOB cache from using too much disk space. When the total size of all files in the BLOB cache exceeds the configured size limit, the BLOB cache removes the least popular files until the cache is below 70% of its configured maximum size. This process is called compaction.
  • max-age: (optional) specifies the maximum amount of time (in seconds) that the client browser caches BLOBs that are downloaded to the client computer. If the downloaded items have not expired since the last download, the same items are not requested again but retrieved from the browser cache. The max-age attribute is set to 86400 seconds by default (that is, 24 hours), but it can be set to a time period of 0 or larger. So it doesn’t specify the invalidation of the BLOB cache BUT additional caching on the client browser.

Optimization for anonymous sites

The BLOB Cache is highly optimized to serve anonymous requests. In an Anonymous scenario no extra SQL Server roundtrips are made to check the user permissions on requested items. Additionally, on lists and libraries you can set the property AllowEveryoneViewItems to true to allow everyone to view items. Setting this property to true prevents the server from checking permissions.

The Styles library, which is a standard library in a publishing site, has this setting by default. The SiteCollectionImages library is also a standard library but it does not inherit permissions from the site and thus this property should be checked.

You can’t change this setting in the list settings using the browser, but you can change it using SharePoint Manager, PowerShell and through code.

You can change this list property through PowerShell:

$web = Get-SPWeb -Identity "[site url]" 
$list = $web.Lists.TryGetList("[list title]");  
$list.AllowEveryoneViewItems = $true 

But also by using the server-side object model:

using (SPSite site = new SPSite("[site collection url]"))
   using (SPWeb web = site.OpenWeb())
      SPList list = web.Lists.TryGetList("[list title]");
      if (list != null)
         if (!list.AllowEveryoneViewItems)
            list.AllowEveryoneViewItems = true;

When you create your libraries using list definitions, you could set this property in CAML:

     Name="[list name]"
     DisplayName="[list display name]"
     Description="[list description]"
     HiddenList="FALSE" />

How the BLOB cache controls the Cache-Control header in the HTTP Response header

The max-age attribute in the web.config makes that a Cache-Control header is added to the HTTP responses for the files it serves. These headers tell the user’s browser to save these files in the browser’s cache.

If the BLOB cache is not enabled, the Cache-Control header is set to private, max-age=0.

cache control 0

In reality it means that the browser can cache the file but with an Expires date in the past, forcing the browser to go back to the server on each request for the resource:

BLOB cache cache-control header

If the BLOB cache is enabled, the Cache-Control header will be set to something like public, max-age=86400, indicating that the file can be stored in and used from the browser cache for 24 hours:

cache control max age

Because of the HTTP response header the file is cached on the client with an Expires header the day after:

cache control max age cache tab

When the browser needs one of the cached files again, it can use its own browser cache instead of making requests to SharePoint Server. This results in fewer HTTP requests and a significantly reduced page load time. This will be explained in detail in the posts about HTTP header requests and responses.

Cache Invalidation

The BLOB cache invalidates cached files by polling the SharePoint Server for changes. This poll interval defaults to five seconds, but this is configurable. When the BLOB cache detects that a file is modified, renamed or deleted, it is removed from the cache and only added again on a next request. If a list or document library is renamed or deleted, all files from that list or document library are removed from the cache. In fact, the cache removes the item from its index of cached items. The actual file on disk is deleted later (on a configurable interval) after any HTTP connections that might be reading the file have disconnected. Invalidated files are not re-added to the cache until they have been requested again.

Other important points

When configuring BLOB cache you should increase startup and shutdown time of the application pool. The recommended setting is at least 300 seconds. This will give the BLOB cache enough time to initialize or serialize its index on startup or shutdown. Setting this value to 300 seconds does not cause it to take 300 seconds to start or stop, but it does prevent IIS from terminating the application pool until 300 seconds have elapsed. Increasing this limit, especially the shutdown limit, prevents the application from being terminated too soon. If the index isn’t completely serialized it is considered corrupted and the cache is flushed on the next startup.

The disk on which the BLOB cache will be stored must have enough free disk space. This disk should have sufficient IOPs to handle the expected throughput. Avoid using the disk for other processes like search indexes or logging. If you have ULS logging and BLOB cache on the same disk, they will compete on disk usage which impacts performance negatively.

Also, take into account that the cache index uses memory. Every cached file uses about 800 bytes of RAM in the cache index. This can be a significant factor in planning for hardware if the expected number of items is large.

How to flush the BLOB cache

Just be careful when flushing the BLOB cache: when the BLOB cache is flushed it needs to be rebuilt file by file, when a file is requested, which will decrease performance. Sometimes the BLOB cache gets corrupted and in that case you have to flush it on each web front end. Don’t consider this as a daily task that needs to be executed.

The recommended way to flush the BLOB cache is using a PowerShell script. But in some cases when the BLOB cache is corrupt, this will not flush the BLOB cache on all web servers. In that case you can do it manually, but you have to be extremely careful.

Flush the BLOB cache with PowerShell

You can flush the BLOB cache by using PowerShell.

$webApp = Get-SPWebApplication "<WebApplicationURL>"

Flush the BLOB cache manually

I already saw cases where the BLOB cache is so corrupt that flushing the BLOB cache using PowerShell does not clear the BLOB cache completely. In that case you can try to clear the BLOB cache manually but with extreme care and only in cases you have no other option left.. Microsoft will always tell you that it s not recommended and eventually not supported.

  • Disable the BLOB cache in each web.config of each web application on each web server
  • Delete the physical folders of the BLOB cache for each web application on each web server. The location of the BLOB cache folders is indicated by the BLOB cache setting in the web.config.
  • Perform an IISRESET on each web server.
  • Enable the BLOB cache in each web.config of each web application on each web server.
  • Perform an IISRESET on each web server.

Store dynamically generated files in BLOB cache

In Web Content Management, sometimes you have to generate certain files dynamically. A good example is the robots.txt. As these files are not stored in a document library, they are not BLOB cached. But you could develop your own mechanism that does store such files in BLOB cache. Read more about this technique in the blog post Inconvenient caching dynamically generated files in BLOB cache of Waldek Mastykarz.

Troubleshooting the BLOB cache

The BLOB cache is implemented through the PublishingHTTPModule in the Microsoft.SharePoint.Publishing namespace.

The BLOB cache also has its own logging messages in the SharePoint ULS logs. A number of messages are always logged, others are only logged when logging for the BLOB cache is set to verbose. By setting the type to Verbose we can investigate how a certain file behaves when requested by a client browser.

BLOB cache log messages are categorized under Publishing Cache.

Changing the logging settings

You can change the Publishing Cache log settings in the Central Administration. Navigate to the Monitoring page and click the hyperlink Configure diagnostic logging.

Central Admin Monitoring

Locate the Web Content Management category in the Event Throttling section and expand it. Check the Publishing Cache option and set the least critical even to report to Verbose.

logging caching issues

Don’t forget to set this setting back to medium after you have finished troubleshooting, otherwise your logs will get flooded with caching messages!

Understanding the messages in the ULS logs

When a page request comes in, you can clearly see in the ULS logs that SharePoint checks if it can find the file in cache:

RewriteUrl: Found item that could be served out of cache: /STYLE LIBRARY/ING/CSSEDITOR.CSS. b0e77431-7079-4a54-8e49-5132d2a8d740

If the file was not found in cache, it is fetched from the content database and stored in the BLOB cache:

Item '/STYLE LIBRARY/CSSEDITOR.CSS' not found in cache.  Fetching it now.    b0e77431-7079-4a54-8e49-5132d2a8d740
Fetching item with URL '/STYLE LIBRARY/CSSEDITOR.CSS' from WSS      b0e77431-7079-4a54-8e49-5132d2a8d740
item with URL '/STYLE LIBRARY/CSSEDITOR.CSS' has a published version.  Creating cache record.  b0e77431-7079-4a54-8e49-5132d2a8d740

If on next requests the file was found in cache, it checks if the requested file has a published version and if permissions need to be checked:

 Item ' /STYLE LIBRARY/CSSEDITOR.CSS' was found in cache.  Now need to figure out if this request has rights to see the published version.      fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91

SharePoint comes to the conclusion that the file is ok and that it is accessible to anonymous users. Unfortunately this file comes from a document library where the AllowEveryoneViewItems property is set to true. I expected to see no additional ACL check executed in the content database.

' STYLE LIBRARY/CSSEDITOR.CSS ' has no draft nor checked out version and is accessible to anonymous users.  
Sending cached file. fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91
' STYLE LIBRARY/CSSEDITOR.CSS ' is fully cached.  fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91

The file is sent from cache:

Request for item ' STYLE LIBRARY/CSSEDITOR.CSS ' is a full file request.    fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91
Completing request.     fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91
TransmitFile for item '/_ STYLE LIBRARY/CSSEDITOR.CSS ' returned (file not necessarily completely sent yet).     fb93c841-0fa5-40ff-beb7-ffdc7fdc0b91

Here is a case of a file that is requested from the document library CustomWebFiles where the AllowEveryoneViewItems property has been set to false. The last log message clearly shows that SharePoint checks if the user has the right permissions:

RewriteUrl: Found item that could be served out of cache: /CUSTOMWEBFILES/ADOBE.JS  0d7586ea-9fb1-43c4-8da3-a7ab0a542645
Item '/CUSTOMWEBFILES/ADOBE.JS' was found in cache.  Now need to figure out if this request has rights to see the 
published version.      0d7586ea-9fb1-43c4-8da3-a7ab0a542645
Item '/CUSTOMWEBFILES/ADOBE.JS' has no draft nor checked out version and is accessible to anonymous users.  
Sending cached file. 0d7586ea-9fb1-43c4-8da3-a7ab0a542645
Item '/CUSTOMWEBFILES/ADOBE.JS' has no draft nor checked out version and is accessible to anonymous users.  
Sending cached file. 0d7586ea-9fb1-43c4-8da3-a7ab0a542645

Here is a case of a file with a draft version. This file will not be served from the BLOB cache:

Requesting user has view item rights for item '/CUSTOMWEBFILES/S_BUSINESS.JS' and the item allows readers to see drafts.  Let WSS handle this request.  6dd2ea35-3412-4eb5-b272-0de1968ec56d


  1. Hi Karine, all of the information here regarding caching in SharePoint is extremely thorough and helpful. Many thanks for your contribution!

    I do have one question concerning the BLOB cache in regards to cache invalidation and the max-age option. As I understand if the max-age option is configured then the browser will download and use its cached version of a given file when rendering the page.

    Suppose this is enabled and an image is changed or updated, perhaps resized. In such case the BLOB cache would be invalidated for that item on the server side but then would the client know to request the new file or would it continue to use the local browser cached file?

    I hope my question makes sense, lol, and thanks again for all of this excellent content!!


    Comment by John | June 14, 2013 | Reply

    • Hi John,
      Thanks for your nice comment!
      You’re right: the BLOB cache on the server get’s invalidated but the resource on the client is cached and used until it expires. By default the BLOB cache max-age is 86400, which is a day because a lot of companies run their content deployment at night. But we have reduced the max-age setting to 7200 which is 2 hours.
      You can also add a revion to your files, like xxx.png?rev=xyz. The rev attribute can be calculated based on the version or the Modified date of your file. In that case your resource gets a different rev value each time it’s changed. The client browser will see that a different file is referenced in your page and will request it from the server.
      Kind regards,
      Karine Bosch

      Comment by Karine Bosch | June 16, 2013 | Reply

  2. Include specific folder content in BlobCache SharePoint :


    Comment by hemantrhtkHemant | October 30, 2013 | Reply

  3. Hi Karine, thank you very much for this useful information. I just want to add the information that you can download a SharePoint solution at Codeplex that allows a Farm Administrator to adjust the BlobCache settings via Central Administration. So you don´t need to modify the web.config file on all web servers manually. You can download the solution here: http://blobcache.codeplex.com/ .


    Comment by Karsten | October 30, 2013 | Reply

  4. Karine – useful article, thanks

    Comment by Syed Ahmed | April 23, 2016 | Reply

  5. Hi Karine – is enabling or disabling Blob cache make any impact of IIS log files in term of file size or we can say if blob cache reduce the log entry in IIS Logs.

    Comment by Abhinav | July 28, 2016 | Reply

    • Hi, the impact on the IIS logs is neglectable.
      Kind regards,
      Karine Bosch

      Comment by Karine Bosch | July 28, 2016 | Reply

      • Thanks Karine for the quick response.
        Actually, I want to know why the IIS log file size is growing too much whenever we are disabling BLOB Cache.

        If we re-enable blob cache it goes down to 3 times less then the duration of blob cache was disabled.


        Comment by Abhinav | July 28, 2016

  6. I found this article because we’re having a problem with a client keep saying that he sees an “old” version of a pdf file, that was uploaded twice in a short period of time (5 minutes). We have a publishing site with blob cache activated also for pdf with no max-age so it defauls to 86400 seconds.
    He said that if he uses another browser (with which he didn’t downloaded the same doc) he sees the “new” version, same if he goes inprivate.
    I am keen to think that he is seeing the cached version in his chrome browser. I have a question, will a “flush” on the blob cache server side force the client to re-download the same file? If not, I guess there is nothing to do other than wait the max-age limit to invalidate the browser-cached file. I am aware that if I reference the file with a querystring parameter it will force it to re-download. 😉

    As always amazing article Karine.
    Thank you sharing.

    Comment by Arturo Bardelli | October 27, 2016 | Reply

  7. […] a ensuite trouvé cet article expliquant comment effectuer un flush du BlobCache par PowerShell et comment le faire […]

    Pingback by Erreur lors de l’affichage de certaines images dans un site de publication utilisant le BlobCache | SharePointerie.com | March 20, 2017 | Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: