Cache Settings in SharePoint 2010

For Microsoft SharePoint Server 2010 at the Web application level you can configure 3 levels of cache settings that improve the performance of web page loading time. They are as follows.

• BLOB cache - configured in the web.config file in the Web application to which you want to apply the cache.
• Object cache - configured in the user interface at the site collection level, web application level and web.config level. The settings in web.config level will override the other two.
• Profiles cache - configured in the user interface at the site collection level, web application level and web.config level. The settings in web.config level will override the other two.

Blob Cache

For sites that use heavy media content – audio or video, static content or read-only .doc or .pdf files the Blob cache will improve performance of the site and show the results quickly to the users. A SharePoint administrator can modify the settings to add or remove file name extensions of file types to be cached. This functionality lets you either cache as many file types as possible - image, audio, and video files, together with .css and .js, or to restrict the cache to certain kinds of files.

There is one BLOB cache per Web application. By default the size of a BLOB cache is 10GB. When you enable the BLOB cache, you must specify a location on the front-end Web server where the files will be stored. Each front-end Web server has its own local copy of the BLOB cache that is built as requests for files are received as shown below.



If you use load balancing with multiple front-end Web servers, each server contains its own cache. When a file is requested by the first server, it is cached to that server only. If the next request for the same file comes from a second server, a second request is sent to the database server to retrieve the file to the cache on the second server as shown below with an example of a request for the header.png file. Only for the first time when files are written to the disk there is a performance hit. Future requests to the WFE server for that same file is served from the file that is stored in the BLOB cache, instead of being served from the database. This reduces the network traffic and the load on the database server. I have seen performances improve from over 10 seconds to less than 1 second when Blob caching is enabled for a web page.



Points to remember

• When you enable a BLOB cache, make sure the ULS logs are not on the same physical drive as it may result in poor performance.
• Select a drive that will be used by as few processes as possible so that the BLOB cache process does not encounter conflicts when it tries to access the drive.
• If you plan to use the BLOB cache together with an asset library that you expect will be large, consider putting the site collection that contains the asset library into its own Web application so that it receives its own BLOB cache.
• Enable Bit Rate Throttling for media files.
• Specify maximum upload size for a file.
• If the BLOB cache is too small, the delivery of files to users will be slow, thereby reducing the performance of your site. Allow at least 20 percent more space on the drive than the size of the cache.
• Flushing the BLOB cache for a Web application affects all site collections in the Web application.

Flushing Blob Cache

If the BLOB cache becomes out of sync with the content you will need to flush it. This could be set as an auto interval or can be done manually by the SharePoint Farm Admin by cleaning the physical disks.

You cannot use the user interface to flush the BLOB cache. Instead, you use Windows PowerShell and the SharePoint object model to complete this task. The powershell script can be wrapped as a windows task schedule for auto interval of manual run. Following the PS command
$webApp = Get-SPWebApplication "<WebApplicationURL>" [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)
Write-Host "Flushed the BLOB cache for:" $webApp

Replace <WebApplicationURL> with the URL of the Web application whose BLOB cache you want to clear.

Object Cache

The object cache reduces the amount of traffic between the Web server and the SQL database by storing objects, such as lists and libraries, site settings, and page layouts, in memory on the front-end Web server computer as shown below.



As a result, the pages that require these items are able to be rendered quickly, increasing the speed with which pages are delivered to the client browser. Object cache settings can be configured at the Web application level, and at the site collection level. By default, the object cache is on at the site collection level as shown below. For example, individual site collections might have the object cache set at 100 MB, while the Web application might be set at 1 GB. In this case, no more than 1 GB of memory will be used by all the caches on the server.



When a publishing control requests the object cache to make a query to get data for the control, the cache makes the query, not as the user making the request, but instead it makes the query twice: once as the Portal Super User account and once as the Portal Super Reader account. The results of these two queries are stored in the object cache. The results for the Portal Super User account include draft items, and the results for the Portal Super Reader account include only published items. The object cache then checks the access control lists (ACLs) for the user who initiated the request and returns the appropriate results to that user based on whether that user can see draft items. By adding the Portal Super User and Portal Super Reader accounts to the Web application, the cache must store results for only two users. So if there are multiple simultaneous users accessing the same object this internal impersonation decreases the amount of memory that is needed to store the cache.

Points to remember

• Optimize the size of object cache depending on the memory available in WFE so that it does not adversely affect the performance.
• Object cache can be used only when publishing feature of the site is enabled.
• The object cache makes its queries as one of two out-of-box user accounts: the Portal Super User and the Portal Super Reader.
• The Portal Super User account must be an account that has Full Control access to the Web application. The Portal Super Reader account must be an account that has Full Read access to the Web application.
• The size is expressed in MB in the web.config file. The default is <ObjectCache maxSize="100" />.
• The accounts configured to be the Portal Super User and the Portal Super Reader should not be user accounts that are used to log into the site. This ensures that the user does not inadvertently check items out and cause problems with performance.
• The Portal Super Reader account should be explicitly configured for claims authentication application else browsing to site collections under this application will result in an "Access Denied" error, even for the site administrator. This error will occur on any site that uses any feature that explicitly uses the object cache, such as the SharePoint Server Publishing Infrastructure, metadata navigation, the Content Query Web Part, or navigation.

Profile Cache

SharePoint Server 2010 adds a more precise mechanism for customizing output caching in the form of cache profiles, which are list-style cache settings that you can name and apply to pages, page items, content types, and levels of scale in your site deployment.

By using cache profiles, you can control the level of granularity applied to output caching; allow or disallow site owners and administrators to choose their own cache profiles and apply them flexibly to page layouts; and target output caching at the site-collection level, the site level, and the page layout level.



You can organize caching behavior based on a user's access rights to a site. For example, you may have three groups defined:

• With full control
• With read and write rights
• With read-only rights.

Output caching renders the page the same way for users with the same rights, so you can use cache profiles to target caching to specific audience groups. In the cache profiles that SharePoint Server 2010 delivers by default, the caching system renders the page once per group of user access rights and then caches the resulting HTML stream. The next user with the same access rights gets the stream from the cache.

Points to remember

• After you create and deploy a cache profile, any change to the cache profile immediately affects all applicable content on the site. For example, if all document library page layouts in a given site collection are initially cached for 60 seconds, and you increase that duration to 120 seconds, every document library page layout in that site collection is cached for 120 seconds, regardless of the number of document library page layouts or sites in the site collection.
• Cache profile can be programmatically extended by VaryByCustom handler.
• Internally it uses the ASP.NET HttpCacheability enumeration. Choices are as follows HttpCacheability.NoCache: Tells the browser, the server, and proxies to never cache this resource. This can be useful for advertisements and resources that are always changing.
  
  HttpCacheability.Private: Only cache on the browser. This will provide bandwidth savings for your users, but your server won't store a cached copy of the output. This is adequate for many sites.
  
  HttpCacheability.Public: The ultimate cache setting: tells the server to save the page, proxy caches to save the page, and the browser to save the page.
  
  HttpCacheability.Server: Only cache the page on the server (output caching without browser caching). However, when your visitors click on your static pages, they will be reloaded.
  
  HttpCacheability.ServerAndNoCache: The same as NoCache except it allows the server to store the page. Has slightly different meaning for remote clients and proxies. Not often useful.
  
  HttpCacheability.ServerAndPrivate: Tells proxy caches to never cache this page, but to allow the browser and the server to cache it.
• This caching should not be used with sites using a low read to write ratio because frequent changes to content make it hard to keep the cache fresh.
• In a load balanced environment this type of caching may affect consistency.