Prelude
I started to write this set of articles as one at the beginning, but I quickly realized that I had a lot of things to explain. Moreover, I’m a real chatterbox which does not help in that case. I finally decided to write a trilogy. I will publish one article every two days beginning today. The code sample will be delivered with last article so I ensure that you read everything ;-). Have a nice reading and do not hesitate to comment.
Introduction
Performance is a recurring problematic when we develop SharePoint solutions.
This topic is huge and many posts would not be enough to cover everything, so I’ll focus on one specific point which helps us to improve performance: data caching.
SharePoint 2010 already had numerous caching mechanisms. An interesting summary is available here
As a short recap here are the caching mechanisms that you could use so far:
Output cache: caches publishing sites generated HTML, server and client side.
Object Cache: caches SharePoint internal objects and requests.
BLOB cache: caches large files (images, videos…) on web front end servers local hard drive.
ASP.NET Cache: caches objects in IIS memory. Things are getting complicated when you have to keep consistency between multiple WFE’s.
BDC Cache: when you access an external service, allows you to decrease back and forth’s.
Some of us also use other mechanisms like:
IIS in memory caching (static references most of the time), is still problematic for consistency.
Session cache, causes troubles when large amount of data, only valid for a given session (“private data”), not consistent (can be avoided with ASP.NET Session state provider)
Http Context cache: is only valid for the request, often used to share large data between multiple components within a same page.
SharePoint 2013 comes out with an important new feature: the distributed cache service. A lot of IT-pro’s already talked about it (and complaint about it, me included )
This new caching service is a real improvement for applications requiring a lot of resources.
I already mentioned it in my last post on the subject but the main principle is to build a caching cluster on top of the SharePoint farm. The topology varies from one single node on a single server farm to multiple dedicated hosts in larger farms.
