asp.net - Suggestions for simple .NET distributed caching solution

Question

We have one server running Windows Server 2003 for our production web server. Our web site has different modules to it and each is ran within it's own application pool. This makes caching a bit of a problem since each module has it's own cache and often times multiple modules cache the same items. The problem is when an item in the cache is altered in one module, another module caching the same item cannot easily be refreshed.

Our site is written in ASP.NET 4.0 and we cache datasets, business objects, collections, lists, etc. using the standard HttpRuntime.Cache object as a simple key/value store. We don't use any file dependencies but we do use a time expiration. We only have about 400 users at once so we aren't doing anything too crazy.

It sounds like some sort of shared/distributed cache would help resolve this issue but I am not sure which one to use or if it would be better to roll our own since we do not need a lot of the features available in most of the products I've seen. I've seen some examples using WCF but most have suggested not to use their examples in production and I know little about WCF.

I'm looking for something simple, fast, lightweight, safe to run in production, and preferably free if possible but it does not have to be. It needs to run on Windows Server 2003 & work with ASP.NET 4.0.

Any suggestions or info?

Answer 1

Simple, fast, lightweight and safe sound like things like redis and memcached, which can be very effective as a central cache. For stackoverflow we use redis via BookSleeve (client) but most stores will work similarly. There is also an AppFabric cache, but that is considerably more complex.

Key points though:

• your data will need to be serializable in some way
• if you are currently using cache of large objects (like a big DataTable) you'll need to consider bandwidth implications, or make it more granular
• you'd probably benefit from a 2-tier cache (one local memory, with the central store as secondary)
• which means you'd also need to consider invalidation (we do that via the pub/sub API in redis)