Distributed Caching - Strategies and Tips
As I have mentioned recently, we (Telligent) are starting to implement distributed caching in Community Server and will likely build it in early in some of the other product work we are doing. While we are not yet done with this work, there are some early patterns and tips I think you will find helpful.
Don't count on it.
Similar to ASP.Net's out of the box in-process cache (HttpCache), you must always assume data in the cache does not exist.
Do not update objects in the cache by reference.
Using HttpCache, you can update objects in the cache without pushing the updates back into the cache. Once you start distributing your cache and jumping in and out of process, you will need to explicity push updates back into the cache to ensure the other servers utilizing those objects will receive the change.
Do not over jump.
In most cases, using distributed caching requires you to jump out of process. However, you should (almost) never jump out of the process for the same object twice on the same request. To accomplish them, consider caching objects in the HttpCache for a very short period of time or utilize HttpContext.Items for per request storage.
Isolate the Cache.
For various reasons, you may not always need distributed caching and may find developing locally without it to be ideal. You should consider isolating your caching access behind an interface which would allow you an easy pattern/strategy for swapping out cache at runtime (provider/factory patterns).
Avoid duplicate object caching.
(This is also valid for HttpCache.) Applications will often cache lists of objects which can lead to duplicate copies of an object in the cache. As an application grows it can become more complicated to ensure object changes are replicated through out the cache when "copies" of the object are in various lists. In addition, each duplicate object in the cache takes up memory space that could be used by another object.
Consistent and predictable cache keys.
As you scale (add servers) with distributed caching it will become increasing important to clear cached items when the object's state has changed.
If you have any other tips, suggestions, or strategies, please leave them in the comments.
Similar Posts
-
Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #142
-
Debug Managed ThreadPool vs Win32 ThreadPool (pre-Vista) Web DOM DocumentFragments - document.createDocumentFragment
-
ASP.NET DropThings: Open Source ASP.NET 3.5 AJAX Portal - new and improved [Via: BradA ] ASP.NET - Render...
-
Link Listing - July 26, 2008

Comments
Steven Harman on on 7.22.2008 at 9:18 AM
w/r/t: Avoid duplicate object caching.
Do you have any advice, suggestions, tips, or patterns we can use to avoid this? Or perhaps just a simple story of what should be done instead.
Colocation Karl on on 7.22.2008 at 11:08 AM
Great post. We started using memcached in a number of applications and have found not only a solid performance gain(use GigE or better only!!!) but it makes it much easier to scale the popular sites.
Scott Watermasysk on on 7.22.2008 at 4:39 PM
@Steve
The general pattern we are considering is to cache each object in the list individually and then cache lists/arrays of ids related to those ids.
We have employed this pattern for a year or so in CS for users and it has worked out well (although we are cleaning it up a bit now).
This means it is very easy to kill or update an item by id and have all the lists which reference it get updated.
Jaime on on 7.23.2008 at 9:25 PM
Also, test you cache code for hits and missies, you don't want to cache something that you will never end up using (ie. it always or regularly expires before you use it again).
Great post!