Explanations, tips, tricks and warnings
Explanations
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.
Tips and tricks
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.
Warnings and disadvantages
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…)