SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.
Related articles in this article series
Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState
Part 3 (this article):
In this article I will talk about some different techniques for managing caching in your applications. One of the most important thing for most projects today is to keep the performance to a maximum under heavy load times. Caching helps out in achieving parts of that goal.
Some caching techniques in SharePoint 2010
In SharePoint 2010, there’s a few different ways to cache data. In this section you can read about a few of those approaches. Most of the caching techniques I use regularly as a developer derives from or is a direct usage of the capabilities of the .NET framework.
Output Caching (Configurable)
The concept of Output Caching is something that natively comes with SharePoint 2010, as it builds on and relies on ASP.NET caching techniques. This means that you can configure your SharePoint 2010 site to cache the Pages it outputs. The reasoning behind caching a page is obviously that it takes time to generate the content on any page, and on a heavily accessed site it would be a performance impact to generate a new page on every request – that’s where Output Caching comes in handy.
There’s a few goodies about Output Caching, as well as a few gotchas that you should be aware of before taking the journey of configuring your sites for Output Caching;
- Positive: Quicker response time for your cached pages, faster to render to the client.
- Positive: Saves on CPU, since it doesn’t have to re-do all the calculations every time.
- Positive: You can customize Output Caching by using Cache Profiles.
- Positive: The caching mechanism can store different versions of the resources cached depending on the permissions for the requesting user.
- Negative: Caching obviously eats more memory as it needs to cache the pages.
- Negative: Possibility for inconsistencies between WFE’s in a multi-server farm.
- Negative: Output Caching is a SharePoint Server 2010 capability.
You can create custom caching profiles for your SharePoint 2010 site which allows you to modify and configure the way things are cached – and what should be cached.
Object Caching (Configurable)
In SharePoint Server 2010 you’ve got the option to use Object Caching as well, which is a mechanism to cache specific page items. This is especially likable if you’re playing around with Cross-List data queries and need to cache the results of such a query.
BLOB Cache (Configurable)
In SharePoint 2010 you also have something called the BLOB Cache, which is a disk-based caching mechanism that caches resources on the disk. Normally these resources are files served by a web page and are named Binary Large OBjects (BLOB).
Normally the BLOB cache will cache files served by the web request like images and video clips.
In web.config you’ve got something similar to the following line which lets you know what file types are cached. You can of course add or remove file types here:
Caching in code (Programmable)
While we know that there’s pre-configurable caching available in SharePoint 2010 (like the Output Cache and BLOB Cache), there’s obviously still a need to create custom caching routines in your applications.
In order for your custom applications to run efficiently and save on server load, you need to consider the importance of using proper caching in your applications.
For instance, if you’ve created an application that is (on every request) fetching information from a database or a SharePoint list (SPList), do you really need that data to be fetched directly from the source – or could you live with having it cached for a few minutes? If it’s not super-important data we’re dealing with that doesn’t need to be up to date every second and every request – please consider building some caching mechanisms in your applications.
There’s a few different approaches to caching in your custom applications, the most common being the ASP.NET Caching (Read about how you can cache a Web Part).
To be honest, there’s no need to write about all the different code-samples you could use for caching right here, as the guys at Microsoft did an excellent job talking about it in this Best Practice article:
Note that the aforementioned article is for SharePoint 2007 (WSS 3.0) originally, but these techniques still apply.
In this article you’ve read about a few approaches to make your applications perform better in SharePoint 2010. These techniques are a fundamental part of development and configuration when it comes to playing around with SharePoint and making it behave properly in terms of responsiveness and performance.
I’ve been getting a few requests for talking about some various caching techniques in SharePoint, so there you have it. Go have a read at those links and you should be all set to start the adventure that is caching!
Latest posts by Tobias Zimmergren (see all)
- Integrate SharePoint Code Analysis Framework (SPCAF) in your TeamCity build configurations–Improving your SharePoint and Office 365 ALM - April 13, 2015
- Office 365 API Sandbox – Learn how to use the API’s with your own tenant data! - February 3, 2015
- Getting Started with building Azure WebJobs ("Timer Jobs") for your Office 365 sites - January 9, 2015