In-Memory Performance

Matt Savona matt.savona at
Thu Aug 4 10:57:45 EDT 2011

With Eric's suggestion, I re-ran my test using R=1, and the read
performance got much better. Those results can be seen here:

If you compare Riak using the LRU cache backend and Membase, it
Membase is still roughly twice as fast for this particular test.

Not being intimately familiar Riak yet, there is definitely some small
amount of overhead per request, the sum of which becomes apparent in
my test. Basically, if you subtract network latency from my tests, and
you are working with objects that are purely resident in RAM then
whatever operations Membase must perform to retrieve an object versus
Riak seem to show that Riak is doing more work to fetch that object,
as Ryan mentioned in his email the other day.

I guess I was just naively assuming that for objects resident in
memory, regardless of the technology, retrieval times would be fairly

If anyone has any other tips, I would definitely be interested to try
them. We have concerns about Membase presently too, though performance
is not one of them presently, my data feels "safer" in Riak and I'm
still interested to see if I can make it work the way we need.


- Matt

On Thu, Aug 4, 2011 at 10:23 AM, Ryan Zezeski <rzezeski at> wrote:
> On Wed, Aug 3, 2011 at 4:54 PM, Les Mikesell <lesmikesell at> wrote:
>> Are you confusing membase with memcache?  The former is a persistent,
>> replicated store, or at least that is the claim; the latter a cache.
>> --
>>  Les Mikesell
>>   lesmikesell at
> Les,
> You are right, I was thinking of memcached when I wrote that reply.
>  However, I don't know if that changes much of what I said.  Looking at
> membase docs [1,2] it is essentially a drop-in (they use the term "OTC" for
> Over The Counter) replacement for shops traditional memcached deployments
> but adds persistence, replication, etc (although, I thought I remember there
> being two different kinds of buckets in membase, one that is persisted and
> one that is not, what's the default?).  Looking at the vbucket literature it
> sounds to me as if replication is something you decide to add, not on by
> default [2].  Furthermore, it's a master/slave replication strategy which is
> different from Riak's quorums.  For example, when doing a read against Riak
> with N=3 it will _always_ contact 3 vnodes even if you set R=1 (it just
> won't wait for all 3 replies).  Contrast that with membase which will only
> perform a read from the master which will be less expensive because you
> don't have to perform coordination on the replies.  For a membase deployment
> to kinda look like a Riak one it should have 2 replicas using a one-to-many
> strategy (as well as being persisted to disk).  I'd be interested to see how
> the two would compare but now I'm drifting off topic a bit.
> -Ryan
> [1]:
> [2]:
> _______________________________________________
> riak-users mailing list
> riak-users at

More information about the riak-users mailing list