This cache cluster is in facts made of appfabric hosts (caching services). One of the advantages is that hosts not members of the cluster but clients of it keep a local copy of objects. And this copy is automatically maintained up to date. The result is you do not need to implement a lazy loading pattern to avoid back and forth on the network.
How does it work? It is very simple. The cache cluster is divided into partitions (defined by SharePoint, se enum SPDistributedCacheContainerType ). You cannot create a partition dedicated to your application. Try to cache your data in a partition which makes sense with what you are doing.
Cached data can also belong to a region. You can create regions if you need to, regions will allow you to interact with your data in an easier way.
Distributed cache also provides a solution for locking/unlocking problematic. Methods are available to manage locking status. You also have access to information about your cached data like version last update, locking status, data expiration date… This can be very useful for advanced usages.
This cluster is not only accessible from IIS Context. That means you can read/write in/from the cache from a timerjob, a service, etc. This is useful when you want to pre-load data in cache.
Another information to consider: the kind of data you store in the cache. You will get better performances if you cache only frequently used data (and not necessarily all data) and/or data requiring of lot of time to process (like calculated data for a report for example). Avoid storing big objects in cache, they take time to load over the network and it can increase a lot latency, moreover you take the risk to fill the cache quickly. Prefer smallest possible objects, if you have objects collections for example, try to reorganize and spit data, even if you have to maintain an index (or many).
I personally advise you to always set a region to your cached data. It is always useful, especially when you need to flush your data and reload everything.
During development, it often happens that your cache cluster does not work anymore. This caused by continual deployments and debugging tools. Open SharePoint Management Shell and issue this two cmdlets: use-cachecluster, then restart-cachecluster. Wait until you do not have any fragmented partition (get-cacheclusterhealth) and you can debug again!
Last tip, I never store fully typed data in the cache. I serialize data before (using a dictionary for all properties for example). Why? AppFabric can perfectly store your typed data. Though, I observed that when you do that, it has a tendency to load your assembly in it’s applicative context. It is really annoying on a development environment where you are continually redeploying and when this can lock the dll and make the deployment fail.
Warning, SharePoint comes with a particular (old) version of AppFabric, do not modify anything in hosts’ settings without using SharePoint powershell cmdlets. Do not try either to update the SharePoint version of AppFabric, this is not supported.
A disadvantage with this version of AppFabric, it does not allow you to use metadata. Let’s say for example we have a data “credit card” which is related to “bank” and to “user”. To make credit cards usage I could tag each credit card with bank-<bankID> and user-<userID>. This would allow me to easily retrieve credit cards by user and/or by bank. Unfortunately this is not possible with this version of AppFabric and in that case I have to maintain indexes of cached data myself, with the involved risks.
You have to understand that you are not the only one to be able to access your cached data. Your data have an expiration delay and can “disappear” if data lifecycle is not properly managed. If the cluster is out of free space (less than 10% free ram on a host), it will start cleaning up data. Finally, do not store sensitive data and consider the fact that, for many reasons, the cluster can be down while your solution is still up.
The last disadvantage is an architectural one, your application relies on one more software component: the cache cluster. If this one does not work or does not work well (because our itpro’s friends do not always do their job properly :P), your solution could not work anymore. This is something your have to think about when coding or even in your disaster recovery/continuity plan. Depending on the importance of your application you can choose to let it fail when the cluster is down, to fallback to a minimal service mode, to fallback to load data directly from the database or even choose not to implement this cache. It all depends on the constraints of your project. Note that if the cache cluster ids down, a lot of built-in SharePoint features won’t work anymore or slower. (social, security, pages loading time…)
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.
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.