Too few articles on Internet talk about the necessity of having a dedicated Distributed cache in Sharepoint 2013. a little reference here 1 but mainly this post of samlman 2
In our company we started with the exact same idea: we knew the distributed cache was storing a lot of information required by users, so let's host in on our web front ends ! It seems we have trouble ? fine, let's onboard new frontend servers and more RAM on all of them.
It ends up badly: our platform was still unstable, crashy and users often get redirected to our ADFS/claims login page (meaning that a lot of background queries such javascript had the same behavior) .
We tried desperately to adjust the correct Cache size but unfortunately our IIS processes, quite greedy, were always reaching web front ends limits
Unfortunately, we didn't really seriously read the warning message or check performance counters.
The memory usage on the current server is about {0}. This can cause the eviction or throttling of the Distributed Cache Service/
Check the memory usage on the machine.And try to free up some memory or add more ram on the machine. For more information about this rule, see "http://go.microsoft.com/fwlink/?LinkID=224261".
The number of errors related to Distributed Cache was crazy high
increasing the timeout values based on this MSDN blog 3 reduced greatly the number of error, but on rush hours, the distributed cache was still failing.
Finally, waiting for futher platform investment, re-using backend servers which were underused, totally fixed our platform unstability.
My conclusion is, don't hesitate about the topology rework or investment, this distributed cache issue was really frustrating for everybody and the cost of service desk, end users time & trust, IT tweaking doesn't worth the economy.
Keep in mind that monitoring the distribution cache when starting a new farm is always a good idea, either one shoot with performance collector on all servers
Or use the consolidated database provided by sharepoint XXXXX_WSS_UsageApplication
by searching for the CounterId you want in PerformanceCountersDefinitions
table, and then filtering the view PerformanceCounters
with counter you're interested in.
http://blogs.technet.com/b/tothesharepoint/archive/2012/08/09/introducing-the-distributed-cache-service-in-sharepoint-server-2013-preview.aspx ↩
https://samlman.wordpress.com/2015/03/02/dedicating-servers-to-distributed-cache-in-sharepoint-2013/ ↩
http://blogs.msdn.com/b/sambetts/archive/2015/02/17/appfabric-distributed-logon-token-cache-viewstate-cache-is-timing-out-continued.aspx ↩