Part 2: Caching Possibilities in SharePoint 2010

Developing SharePoint web sites is a though hob, but writing performing SharePoint web sites is even tougher.

When an out of the box SharePoint site is visited, a lot of images, CSS stylesheets, JavaScript, ribbon stuff and Client Object Model stuff is sent from the server to the client browser. There are different techniques to cache and even to minimize and exclude the overhead from a publishing page when accessed anonymously. These issues and techniques are handled in “Part 14: Only render the JavaScript files and CSS files you need”, “Part 16: Compress CSS files and JavaScript files” and “Part 17: Minify JavaScript”.

In a SharePoint 2010 environment, a WCM publishing site consists of page layouts based on which content authors can create content pages. These pages are stored in the content database. When a SharePoint site is visited and a page is requested for the first time, the SharePoint page and its master page are retrieved from the content database to handle the user request. If the page contains components rendering data (for example a control that displays a list of productions in promotion), also this data is retrieved from the content database and formatted into HTML. A page also requires CSS styles and JavaScript; these can be stored in a document library (which is stored in the content database) or in the _layouts folder of the SharePoint file system. For each CSS, JavaScript and Image on the page, the client browser will make an additional HTTP request to the server to get this file from the content database or the server itself.

Without caching, the page and its data is always retrieved from the content database. Although this ensures that all users always see the most up-to-date data, it has the downside of requiring constant data traffic between SQL Server and the web front-end servers slowing down the loading of the page to the client browser.

There are different techniques that can be applied to improve the performance of a SharePoint page:

• Minimizing round trips to the content database on every call
• Reduce permission checks on the content database
• Storing files like CSS files, JavaScript files and images from the content database in a local folder on each WFE
• Pre-compiling user controls and pages
• Saving the output HTML of pages
• Reusing database connections and requests when possible

In this part and the 4 parts that follow, I will highlight how you can improve performance of a publishing site, making use of the different caching techniques that SharePoint offers out of the box.

SharePoint has its own caches that run on the web front ends. Caching is the technique of storing local copies of data on each web front-end limiting the round trips to the SQL Server database and ensuring quicker responses to serve the user requests.

There are 4 different types of caching:

Type of caching	What is cached?	Where is it cached?
BLOB Cache	Files stored in the content database (images, css, JavaScript)	On disk on the WFE
IIS Cache	Files stored in the _layouts folder (images, css, JavaScript)	On the browser cache of the visitor
Output Cache	Caches the publishing (.aspx) pages	In memory of the WFE
Object Cache	Caches data objects	In memory of the WFE

The IIS Cache is a special case and is in general not considered as a cache used by SharePoint because it only concerns browser caching on the client. All other caches also allow browser caching. But I always tend to mention it because you can configure IIS Caching on IIS level.

The SharePoint Server caches require additional system resources to store and maintain content and indexes.

Caching can be achieved by configuring settings on web application level and on site collection level. Many developers consider the configuration of settings – and in this case caching settings – as  an infrastructure job but in my opinion a good SharePoint developer needs to understand the different possibilities. Additionally there are different coding techniques to obtain data caching. Some of the classes of the SharePoint Object model use build-in caching techniques, but you can also implement your own caching mechanism. The developer side of caching will not be detailed in this blog post but will be explained in the post “Part 7: SharePoint classes that use built-in caching techniques”.