Distributed Caching (Middleware)---a Technical Reference Guide for Designing Mission-Critical Middleware Solutions

Want more guides like this one? Go to Technical Reference Guides for Designing Mission-Critical Solutions.

Microsoft Windows Server AppFabric Cache delivers an explicit distributed caching solution in the form of an in-memory object unified cache. Servers in the farm are called cache hosts, and are managed collectively, forming the cache cluster. AppFabric Cache generally scales linearly and can scale elastically without cache downtime. AppFabric can store any serializable object, making it much more robust than its open source counterparts, which are typically key-value stores or document databases. Key competing commercial products are IBM WebSphere eXtreme Scale and Oracle Coherence.

Best Practices

Development

  • In case, optimistic or pessimistic locking is leverage them go over the API semantics are per this reference.

  • Develop policies for expiration and eviction, and know how to troubleshoot expiration and eviction.

  • When designing the logical cache, group objects into named caches and understand that all objects within that cache share configuration settings.

  • Classify your cache data and architect your solutions accordingly, especially when thinking about concurrency.

  • If you are using tags to search data, note that a given region is bound to a single cache host and not load-balanced across the cluster. Thus it is only served from a single host, though it is replicated to another host for the purpose of HA.

  • Refer to the article "What Happens When a Cache Host Fails" https://msdn.microsoft.com/en-us/library/ee790974.aspx

  • Minimize the number of DataCacheFactory creations, as it is an expensive operation; consider a singleton pattern.

  • AppFabric cache follows the cache-aside pattern. You may need to prime your cache in advance.

  • AppFabric is a great place to cache ASP.net session state, but you need to carefully classify what is truly session data activity, and what is other cache data (reference, resource).

Deployment

  • Deploy the cache solution (clients, cluster, and storage) within the perimeter of the same firewall. It is not intended as a front/external facing solution.

  • Cache clients should be in the same domain as cache servers; if that is not an option there is a workaround, but keep in mind that latency among hosts must stay below two seconds.

  • Be sure to choose the correct cluster configuration store for your solution.

  • Understand how lead hosts work with cluster configuration.

  • Analyze requirements for high availability and network configuration. If using SQL as the configuration store, consider mirroring with a witness server for disaster recovery.

  • Security settings are applied after configuration, and only on a stopped cluster, so plan upfront.

  • When running under network service, the machine’s local network domain account is used for configuration store access. If you have a lot of cache hosts, take this into account. Note that the use of a domain account is not currently supported.

Management and Administration

Performance

  • Cache servers should be solely dedicated to caching; other server roles (web hosting, file server, database) should be placed on different servers. This will also increase reliability.

  • AppFabric Cache provides login and counters to assist in monitoring. See other details here.

  • Know how to troubleshoot throttling issues and eviction issues.

  • If used in a virtual environment, consider the performance and availability impact of placing the virtual machines on the same host.

  • Be sure to test configurations on production-like hardware to determine whether your solution benefits from scale-out versus scale-up.

Case Studies and References

Examples of successful architectures are described in the following case studies and white papers:

Questions and Considerations

This section provides questions and issues to consider when working with your customers.

Development

  • Are there expiration and eviction policies for objects in the cache? Can all objects exist in the cache at all times?

  • Are named caches being used to partition the cache for logical grouping and/or high availability (HA)?

  • Are you required to search for objects within the cache?

  • Are you classifying your data when designing the cache? Are you caching ASP.NET session state?

  • Are you using cache-aside pattern or priming the cache in advance?

Deployment

  • Are the cache servers and the cache clients in the same domain?

  • Is the cache configuration stored in XML, Microsoft SQL Server, or a custom provider?

  • What are the HA/DR requirements for the cache?

  • Are there any security requirements for the cache?

Management and Administration

  • Is there a plan for adding or removing servers from the cache cluster or restarting the cache cluster?

  • What are the monitoring requirements? What tools does the enterprise use currently (System Center Operations Manager, NetIQ, and so on)?

Performance

  • Are the cache servers dedicated to caching, or do they provide other services?

  • Are the cache servers running on a virtual or physical machine?

  • What are the service level expectations (for example, through and latency) and metrics (for example, size of cache and number of objects)?

  • What is the performance test plan, and does the solution benefit more from scale-out than scale-up?

Appendix

< Full URLS for Hyperlinked Text>