Home > Administration, Configuration > SharePoint Cache

SharePoint Cache


Caching is very important to improve the performance of a site. When it comes to SharePoint, it is a kind of grey area because you don’t know how the cache headers are set or on what logic are they set. SharePoint set’s the cache header based

case 1:  Content delivered from file system (typically _layouts folder)

case 2:  Contents that are delivered from Content DB (like Doc library, Picture Library etc)

In case 1, the files that are delivered are not private. And will have max-age value set to some number (more than 30 days i believe). And all the subsequent requests to these resources will be delivered from cache. Unless until you clear the cache most of the content are delivered from cache.

In case 2,  there are two sub scenario’s one with BLOB cache enabled & one without BLOB cache enabled.

First without BLOB Cache enabled, the cache headers delivered will be something like ‘Private, Max-age:0’ & expiration will be 15 days before current date. (Don’t know why is that so). This means that cache is private (meaning that user can cache this content) and all subsequent request to this resource will be used from cache after checking with server that the content is not modified.

You can notice HTTP status codes 304 for these requests which confirms that content is not modified. Each content is generally delivered by server with ‘LatModified’ date. This means a round trip to the server is involved but no data is transferred if the content is not modified.

Even this ‘304’ status involves some operation on the server. As the content are stored in DB, only a DB query can tell if the content has modified after a specific time. So, when targeting large users (may be in ten’s of thousand) avoid this is also a good idea. And enabling BLOB cache is best option.

Now with BLOB cache, the cache is public and max-age is ‘86400’ which is 24 hours. And all the subsequent request for these resources will be from cache unless you clear the cache or if you do ctrl+f5. In this way a round trip to the server is avoided to check if the resource has been modifed or not.  And this involves some DB operation as described before.

TIP: When using Fiddler don’t press F5 to analyze the cache, because F5 behaves differently and our Content db items will be need to be verified for latest version before serving to the browser.

Hope this helps someone.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: