A short overview of cache providers, part 2

The short overview of cache providers continues with two more of them – NCache and Velocity.


As a surprise – it doesn’t come free! So our (my) expectations should be even higher. But hey – it has a free option as well! So – what we get from NCache?

  • Enterprise Library pluggability – this can be useful, but doesn’t seem to be unachievable using the other providers as well…
  • HttpModule for 1.1, Session handling module for 2.0/3.0/3.5 for putting asp.net session into cache
  • Can handle java and .net clients natively
  • You have the option to build complex hiearchies, clusters, etc

So – this looks like heaven, or not? The trick lies in the limitations for the free version:

  • Only a maximum of 2 servers supported
  • Cache clients should be either local or from the second cache server
  • Only the replicated cache topology can be used
  • No support for session state/output cache (means no module)
  • 32-bit only (which would mean a 2 Gig cap on cache size, but it’s limited as of 500 Mb anyway…)
  • No java clients, no remote .net clients
  • No SQL dependency
  • No event notifications (!)
  • No GUI tool

So most of the limitations are rock solid and stops me from using this, sorry…

Microsoft Velocity

Microsoft Velocity is anotherdistributed cache platform for in-memory caches spread across multiple computers. The Velocity API is in managed code, and as usual – any serializable managed object can be in the cache. So let’s look at the bells and whistles and the downsides:

  • It’s running as a 32bit process – in order to use more than 2Gigs you have to run more of them
  • It has session state provider module for asp.net
  • It supports regions as another level of separation as well as asynch communication, locking and TTL
  • Planned support for failover, replicated cache (currently only local/partitioned/routed available) and eventing

So if it’s at least as good as the others why not using it today? I have to admit – I’d miss many of the planned features… And as it looks like currently, CTP2 is on the way to be delivered at PDC, and RTM is targeted to be in H1CY09…

Of course – this is not a full list. If you know any cache provider you think may worth showing here – don’t hesitate. And I’ll try to come to a conclusion in the part 3 – so be prepared!

Technorati tags: , , ,

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 🙂