UNDERSTANDING SHAREPOINT 2013 DISTRIBUTED CACHE SERVICE AND FEEDS

In SharePoint Server 2013, Microsoft managed to improve performance by storing objects and data across servers to enable the accelerated execution of many different types of requests and operations. The Distributed Cache service, which is built on Windows Server AppFabric Cache, is set to run in a collocated mode (Dedicated Mode, if more than 10,000 users) on all SharePoint 2013 Servers by default, using up to 10% of the server's total physical memory.

Improving SharePoint 2013 performance relies on the provision of caching functionalities to some key SharePoint features including:

§  Authentication

§  Newsfeeds, micro blogging and conversations

§  OneNote client access

§  Page load performance

§  Security trimming

Caching functionalities, provided by the Distributed Cache service, enable the SharePoint features listed above to quickly retrieve data without any dependency on databases stored in SQL Server, as everything is stored in memory.

The Architecture – How social feeds works with Distributed Cache

Capacity planning for the Distributed Cache service

The following table lists different memory and architecture recommendations for the Distributed Cache service, depending on the total number of users.

Deployment size	Small farm	Medium farm	Large farm
Total number of users	< 10,000	< 100,000	< 500,000
Recommended cache size for the Distributed Cache service	1 GB	2.5 GB	12 GB
Total memory allocation for the Distributed Cache service (double the recommended cache size above)	2 GB	5 GB	24 GB
Recommended architectural configuration	Dedicated server or co-located on a front-end server	Dedicated server	Dedicated server
Minimum cache hosts per farm	1	1	1

  

 Considerations when implementing Distributed Cache

• As the warning above strongly suggests, do not manage the Distributed Cache service through either the Services MMC snap-in or the generic Windows Server AppFabric tools! Use SharePoint Central Administration and the SharePoint PowerShell cmdlets designed for the purpose.
• There must be at least one cache host in the farm running the Distributed Cache service
• Anytime you need to shut down the Distributed Cache service on a cache host (via Stop-SPDistributedCacheServiceInstance cmdlet), such as to remove a cache host from its cache cluster, use the –Graceful switch to avoid data loss. Although it takes longer to shut the service down this way, cached items are preserved (i.e., transferred to another cache host) and end-users get a better experience.
• The Distributed Cache service must be shut down on a cache host before certain operational and maintenance tasks.
• The Distributed Cache service must be shut down on a cache host before it is decommissioned as a cache host.
•  If your SharePoint Servers (specifically, your cache hosts) are virtual machines (VMs), do not use dynamic memory for those VMs. Dynamic memory allows you to squeeze “more” out of a hardware host, but it can cause problems for the Distributed Cache service since actual physical memory assigned to a VM is variable. For Distributed Cache cache hosts, used fixed memory allocations in your VM configurations.
• When adding and removing cache hosts to a cache cluster, be aware that the Distributed Cache service depends on Internet Control Message Protocol (ICMP) for operation – likely to ping other cache hosts to determine their availability and readiness. This may require you to make firewall changes in your environment and on your cache hosts.
• All cache hosts in a cache cluster should be configured with the same Distributed Cache service memory allocation, and that value shouldn’t be less than 8GB per server.
• Don’t allocate more than 16GB of memory to the Distributed Cache service on any single cache host – even if the system has more RAM available. Allocating more than 16GB of memory may cause the server to stop responding for periods in excess of 10 seconds.
• The maximum number of cache hosts per cache cluster is 16.
• The Distributed Cache service on a cache host throttles requests when memory consumption approaches 95%. Until memory utilization levels drop back to (approximately) 70%, cache read and write requests are not accepted. Keep an eye on memory usage and the Event Log for signs that a server is memory starved and consider adding additional cache hosts in such circumstances.
• The SharePoint 2013 Health Analyzer has a few rules that will surface issues with the Distributed Cache service. Keep an eye on Central Administration and Health Analyzer Reports.