Partager via

BlobCache woes, how to work (clean) correctly with it, and what to expect when using it with SharePoint features

  • Article

I ran into an issue with BlobCache lately where it was sending incorrect Http headers.  Basically, all files were sending 2 http headers:

  • Exires : (15 days behind)
  • cache-control: private, max-age=0

 

Yes, "exires", not "expires", so not only we have a bug but also a typo :)  Anyway, this was ensuring that all static content wasn't properly cached by proxies and browsers and it was impacting performance big time.  Now, before going into the details of this, let's explain what is BlobCache first.

 

The main function of the BlobCache is to cache large objects from the database to the web front-ends.  Its configuration is simple, you specify which extensions you want it to trap, a local folder to drop the cached files on the WFEs, an expiration (in seconds), and whether or not to enable it.  Sounds fairly simple and it is (until it doesn't work correctly).  Now BlobCache has a secondary function which is to send "better" Http Headers to clients so that they can also cache the files along the way.  Basically, it will send a "Cache-Control: public, max-age=86400" to the browser and by having it public, it means that anything along the way (proxies) can cache it.  The 86400 is the default value for max-age if you don't specify it and it means that the file will expire in 1 day.

 

In my case, I am using features to deploy the static CSS, JS, GIF, JPG (along with master pages & page layouts); this means that they are already on disk at each WFEs.  Technically, I don't care to have BlobCache for those and would only need it for images that authors add to their publishing web site.  What I really need for those files is the "cache-control" header that the BlobCache sends.  I also have a setup with 2 SharePoint farm: 1) for authors only, and 2) we use content deployment to publish the first farm to the 2nd for visitors.

 

First problem encountered: BlobCache doesn't always work correctly with the authoring farm.  For some (still unknown) reasons, files that are coming from a feature, which means that they aren't in the database, are sometimes corrupted.  I had 2 different behaviours: 1) images were half working where I could see parts of the images and the rest was blacked out;  and 2) JavaScripts files are simply cropped. I haven't resolved that one yet; I was able to determine that it only was acting like this with files that are already on disk.  For example, I unghosted a corrupted file and it was correct at that moment.  I also did a "revert to definition" and it kept working (so I'm assuming that it's still in the database but to its original version).

 

Fortunately, when you use Content Deployment, any files that are in Style Library will be sent to the destination, even if they come from a feature.  Of course, it requires the feature to be installed (but not activated) at the destination but it will only activate it at the end of the import process.  That means that, at the destination, the files are in the database and I do not have a BlobCache issue when files are in the database.  So normally, in the production environment, my cache-control header should be fine.

 

And it was until it stopped working after a deployment.  When it started failing, it was showing the 2 headers I wrote in the beginning.  I tried flushing it through the GUI (Site Settings - Site Collection Object Cache - Force flush on this server), deleting the files manually on disk, doing an IIS reset; but I kept having the issue.  Then I found the following :

 

If you have multiple zones (i.e.: you extend a web application), each of them has its own BlobCache folder.  It also means that the "Force flush" only works for the zone that you are pointing to in the URL.  Also, it only flushes it on the server you are on (in the URL).   So if you have a load-balanced URL, play with a host file :)

 

In my tests, the ideal way to make it work is to, for all servers:

  • Use the GUI to flush the BlobCache for all zones
  • Optionally, delete the content of your C:\BlobCache (by default) folder
  • Use IISRESET

 

I tried this several times and it was fixing my issues with the incorrect Http Headers and now SharePoint had much better performance.  I still have to find out why it's not working with items that aren't in the database (for my authoring environment).

 

Maxime

Comments