The future at Microsoft is cloudy, with an increasingly bleak chance of on-premises. It's interesting to see how Microsoft is aggressively transitioning into a device and services company, and that on-premises applications are getting step-child treatment lately. Almost all of the innovation lately happens on or for the cloud, and if we are lucky, we get morsels of treats in our on-premises doggie bag. I'm not complaining, merely observing. A move to the cloud makes a lot of sense.

One such treat that has made it to on-premises applications is distributed cache. In fact, distributed cache has been available on-premises Windows Server for a while. A very long time ago, I wrote a couple of articles for CODE-Magazine hinting where we are headed, including one that was about Office 365 and Azure (http://www.code-magazine.com/Article.aspx?quickid=1108021) and another that was about Session State in SharePoint 2010, using AppFabric (http://www.code-magazine.com/Article.aspx?quickid=1109021).

The name AppFabric has bee n retired since, and the product has been firmly put in the .NET 4x camp. But it is the same product, and it is incredible. I've had the pleasure of bumping up performance for a data-driven app by about 400 times in a project, using a network of old desktops configured to work as a distributed cache farm. All of this was on-premises, and the benefits are even more apparent in the cloud.

There is another thing that has changed though: SharePoint 2013 now makes full use of Distributed Cache, right out of the box. And you can tweak it further to suit your needs. No wonder SharePoint 2013 is so RAM-happy, but given enough RAM, it blows the pants off of SharePoint 2010 when it comes to performance. There are many reasons for that, but one of the major reasons is distributed cache. Note that distributed cache is different from BLOB cache (which is a disk-based cache that uses the disks of every Web front end), and output cache (which is an ASP.NET feature).

SharePoint is no stranger to dramatic amounts of information. The challenge in maintaining large amounts of information, is keeping it fresh and available for the end user. SharePoint 2013, makes use of distributed cache to cache newsfeeds, microblogging, conversations, security trimming, OneNote client access, and even keeps the FedAuth cookie for claims based authentication on the server side, so it's more secure, load balancer friendly, and works with webkit-based browsers that like to chop off your cookies at 64kb.

Out of the Box or Configurable

The good news is that taking advantage of distributed cache requires you to do absolutely nothing. As soon as you install SharePoint 2013, distributed cache is already running in a collocated mode, where it shares the WFE's memory. In fact, it allocates up to 5% of the RAM available on the server, up to a maximum of 16GB per WFE.

Frankly, for most implementations spanning a few thousand users, this option is okay as long as you throw enough RAM (64GB) on the server. But sometimes, the boss doesn't give you enough memory, or perhaps your solution is extremely reliant on social features. In such situations, you should consider setting up a dedicated service farm, where the cache cluster is completely separate, with no other SharePoint services running on that server.

You can also take the mid-way approach of using a collocated distributed cache farm, but tweaking cache settings to allow more memory to be available to distributed cache. For large-scale production use, the recommendation is to have dedicated servers hosting your cache. Also, running distributed cache on an already overtaxed server, such as SQL Server, Search, Excel Services, or Project Services, negates any benefit you may garner out of distributed cache.

Administering Distributed Cache

Distributed cache with SharePoint comes with many extensibility/configurability points. You can use the out-of-the-box setup, set up a dedicated cache cluster, add or remove servers from it, or repair or reconfigure an existing cache cluster or host.

Setting Up Distributed Cache

Using distributed cache in most normal circumstances in a collocated mode requires no extra configuration. But in a case where you need to have a separate cache cluster, or a hybrid setup where only some computers act as a cache host, you can set distributed cache up using PowerShell commands, or you can run PSConfig.exe with the /skipRegisterAsDistributedCachehost flag on all servers that are not cache hosts. At a later date, you can also turn a non-cache host into a cache host by running the Add-SPDistributedCacheServiceInstance commandlet. Alternatively, to remove a WFE from being a cache host, you can also run Remove-SPDistributedCacheServiceInstance commandlet.

Repairing Distributed Cache Service

Distributed cache service also ties into the health rules in central administration. You may see “The Distributed Cache host may cause cache reliability problems,” for instance in a health analyzer. Or perhaps the newsfeed on a user's site starts showing errors. In such scenarios, you may need to repair a non-functioning distributed cache host. You can do this by going through the following steps:

Run Get-SPServiceInstance to list all services for all servers in the server farm.

Note the GUID from the ID property of the distributed cache service on the server you are repairing.

Call serviceInstance.Delete() on the offending service instance.

Run Add-SPDistributedCacheServiceInstance to reinstall and start the distributed cache service on the cache host you are repairing.

Reconfiguring Distributed Cache Service

Sometimes you want to reconfigure how much memory has been allocated to the distributed cache host. You can do so by running the Update-SPDistributedCacheSize commandlet on the host you are reconfiguring memory for. You should not exceed 16GB or 40% of the total system RAM. Then you'll need to restart the distributed cache service on all servers in the cache cluster. You can do this through central admin or PowerShell.

Defaults

When you install SharePoint, 5% of the server memory is automatically allocated to the distributed cache service's cache size. The maximum amount of memory that can be allocated to the distributed cache size is 16GB per cache host in the server farm, and the maximum number of hosts per cluster is 16. That is a lot of fast memory to play with. For servers with more than 320GB of memory, should you have such a problem, you must plan to reconfigure the memory allocation of the distributed cache size to take full advantage of the server's capacity. This is because 5% of 320GB is 16GB, and you would hit the maximum limit for out-of-the-box configuration.

In such situations, if the administrator allocates more than 16GB of memory to the distributed cache service's cache size, the server can unexpectedly stop responding for more than 10 seconds. You should never run distributed cache service on a server with less than 8GB of RAM, because so little RAM is not sufficient for even SharePoint 2013.

Servers running the distributed cache service are called as cache hosts. You need at least one cache host per SharePoint farm. Don't worry if you installed SharePoint 2013 on a single computer-that computer acts as the cache host. As more WFEs join in, they become a part of the cache cluster. You can, of course, decide to turn cache service off on any WFE using PowerShell-you may want to do this if you get a new server with only 8GB of RAM when you had asked for 32GB.

The last important note is that if you decide to run a cache cluster, and you are using a few of computers in such a cluster, the cluster needs to be homogenous. In other words, you need to ensure that the memory allocation for the distributed cache's services' cache size on each cache host is exactly the same.

It is also important to note that SharePoint is hard-wired to use a certain version of distributed cache. You can't upgrade the distributed cache version and expect SharePoint to continue to work. Also, SharePoint is a very simple cache client. Even though distributed cache itself supports concepts such as high availability, SharePoint's implementation does not. For SharePoint, if a server dies, you lose the items in it, and SharePoint will have to rebuild the cache on other computers in the cluster farm.

You are more than welcome to use the distributed cache on the SharePoint server in your applications, as long as:

• You create your own cache collections, and don't interfere with SharePoint's functioning.
• You don't go around tweaking the settings of distributed cache in the control panel and therefore possibly breaking SharePoint.

A Few Important Gotchas

The distributed cache setup requires you to know a few things that may not be very intuitive at first glance.

Networking Issues

It is important to realize that the distributed cache depends on certain firewall rules. You need to allow inbound ICMPv4 traffic. With Windows Firewall, you can enable this in PowerShell with the Set-NetFirewallRule cmdlet. The name of the rule is "File and Printer SharePoint (Echo request– ICMPv4-In)". You can use this commandlet, by issuing the command below:

Import-Module NetSecurity.

Set-NetFirewallRule - DisplayName File and Printer Sharing (echo request - ICMPv4-In)" - Enabled True

Reallocating Memory

Let's say that you set up SharePoint with 16GB of RAM and add another 48GB later. When you change the RAM, the distributed cache service does not update its memory allocation automatically. Imagine what would happen if you had to lower the amount of RAM on your server! You can use the Table 1 as a rough guide for setting up the various parameters for your distributed cache size, but remember to tweak these per your specific needs and changing hardware specifications.

In any scenario, you should never go over 16GB of total cache size. If you need more than 16GB, you can add more servers in the cache cluster–up to 16 more-for a total of a 256GB cache cluster farm.

Checking Memory Allocation

Interestingly, the commands for checking the current cache configuration are not SharePoint PowerShell commands. Figure 1 shows how you can find the current cache host configuration.

Figure 1: Getting the current cache configuration.

The Distributed Cache Service Account

This one applies to you no matter how your cache configuration is set up, even if you are using the out of the box configuration. When AppFabric is installed as part of the SharePoint pre-requisites, it is configured to run under the credentials of the server farm. This is far from ideal, and will eventually trigger a violation of a Health Analyzer Rule. Ideally, you should change this account by using the Get-SPManagedAccount commandlet, using the script shown in Listing 1.

Listing 1: Changing the account for your distributed cache

$localFarm = Get-SPFarm
$distributedCacheService = $localFarm.Services | ? {$_.Name -eq "AppfabricCachingService"}
$account = Get-SPManagedAccount -Identity "ws\someaccountname"
$distributedCacheService.ProcessIdentityType = "SpecificUser"
$distributedCacheService.ProcessIdentity.ManagedAccount = $account
$distributedCacheService.Update()
$distributedCacheService.Deploy()

Summary

Performance, performance, performance. SharePoint is resource-hungry, there's no question. But one of the most common mistakes is to install it, and just hope that it performs in all situations for all users.

There is no product that can meet that unreasonable expectation. For something as involved as SharePoint, you need additional tweaking, measurement, and improvements to bring the performance up to a user-acceptable standard.

One of the key improvements is distributed cache, but there are many others. If you ever feel your dev environment is too slow, ask yourself when was the last time you tweaked distributed cache so that it wouldn't eat up all the available memory? Until next time, Happy SharePointing.