Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,124 | Comments: 45,475

filter by tags archive

Distributed cache for the CLR

time to read 1 min | 177 words

Sriram has just published a post about Cacheman, a pet project  his that give us a Memcached like functionality based on the CLR.

I started a project like that a while ago, but eventually I decided that it would be much easier to just use Memcached. Some of the tricks that Memcached is using is explicit memory management of the layout of the cache. I assume that the GC will take care of much of that for us.

Sriram has managed to get to 16,000 requests / second with his current code. Which is certainly impressive.

I find it very interesting because I am much more comfortable with CLR based tools. I know their failure scenarios and how to deal with them. Native tools... not so much.

I have used Memcached for production, and it works. But assuming that Cacheman would be on par with the Memcached implementation, I believe that I will choose it.

I am reading the code now (well, reflecting over it) and it is interesting read.


Nick Aceves

I started a project like that once too. I was able to get somewhere in the area of 10,000 requests/second without any optimization at all. I would really like to see something like Memcached that's built on top of the CLR, and would even be willing to devote significant time to such a project.

It would be even cooler if the server supported the Memcached protocol, which would allow it to act as a drop-in replacement for Memcached.

Sriram Krishnan

Thanks for the post (and the mail!). I'll admit up front that it is a big stretch to think of Cacheman as being anywhere close to being on par with Memcached. One is a stable, well-tested piece of code and the other is something I've thrown together over a few weekends :).

It might get there eventually - but its a long road!

Luke Breuer

I really like your emphasis on failure scenarios. I think I would word it like this: it is easier to determine how failure is flowing through .NET code than most other code. Now, this is clearly based on my experience. I do, however, see quite the trend in people liking how .NET deals with failure.

Now, if people would only document how failure flows through their system, providing information that stack traces do not... (Like the "why", as opposed to the "what".)

Ayende Rahien


Ping Sriram, ask him how you can help him


Thanks for the heads up Ayende. Nice stuff to read.


Comment preview

Comments have been closed on this topic.


  1. RavenDB 3.5 whirl wind tour: You want all the data, you can’t handle all the data - one day from now
  2. The design of RavenDB 4.0: Making Lucene reliable - about one day from now
  3. RavenDB 3.5 whirl wind tour: I’ll find who is taking my I/O bandwidth and they SHALL pay - 3 days from now
  4. The design of RavenDB 4.0: Physically segregating collections - 4 days from now
  5. RavenDB 3.5 Whirlwind tour: I need to be free to explore my data - 5 days from now

And 14 more posts are pending...

There are posts all the way to May 30, 2016


  1. RavenDB 3.5 whirl wind tour (14):
    29 Apr 2016 - A large cluster goes into a bar and order N^2 drinks
  2. The design of RavenDB 4.0 (13):
    28 Apr 2016 - The implications of the blittable format
  3. Tasks for the new comer (2):
    15 Apr 2016 - Quartz.NET with RavenDB
  4. Code through the looking glass (5):
    18 Mar 2016 - And a linear search to rule them
  5. Find the bug (8):
    29 Feb 2016 - When you can't rely on your own identity
View all series



Main feed Feed Stats
Comments feed   Comments Feed Stats