A short overview of cache providers, part 1

In the following few paragraphs I'll try to a give a less-or-more comprehensive view over the world of cache providers. What we call a cache provider? The first thing people generally do is cache things within their web processes. But this means your cache is duplicated multiple times, once for each thread. This is a waste of memory and you'll get low cache hit rates. If you're using a multi-threaded language or a shared memory API like the built-in System.Web.Cache with in-memory settings, you can have a global cache for all threads, but it's per-machine. It doesn't scale to multiple machines. Once you have 20 webservers, those 20 independent caches start to look just as silly as when you had 20 threads with their own caches on a single box. Cache providers' servers and clients work together to implement one global cache across as many machines as you have – like the state server or sql server options for System.Web.Cache. But is the default implementation of System.Web.Cache flawless and perfect? Some says no – there may be improvement both the server and client sides.


Why bother with a linux damon cache implementation made by danga? Answer is easy: first of all – there is a win32 implementation for it. Secondly – there are thons of different APIs to access it from .NET. Three of those APIs am I going to further investigate – the .NET memcached client library, the enyim.com Memcached Client, and BeIT Memcached. (interesting thing to mark – 3 projects, 3 different forge – sourceforge, codeplex and google code 🙂 )

The .NET memcached client library is the one, that mostly follows the schema and technology of the java client – it's a 1:1 port of that one.

The BeIT client comes with many bells and whistles, like socket pooling, uses the ketama algorithm for sticking keys to servers (key – server assigment stays the same even if there are new servers added or removed between), most of the simple value types have their own optimized serialization, have compression schemas, automatic key prefixing, dead server detection, etc.

The enyim.com Memcached client comes with nearly the same set of features, except for an additional one – a provider project to wire it up into System.Web.Cache without any additional steps.

As a special experiment, there are .NET implementations of the memcached server as well, and compared to the native C implementation, they even doesn't work that bad. One of the implementations I tried was part of the experimental hive of the Rhino framework – I'll try to cover that framework in a later post 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *