In-Memory Performance

Matt Savona matt.savona at
Tue Aug 2 20:50:27 EDT 2011

Oh wow. You're right...thank you /very/ much for catching that. I
don't know what gave me the impression that the default was R=1 (could
have sworn I read it somewhere). Can't wait to try this out when I get
into the office tomorrow hopefully it speeds things up a bit.

I'll post some revised numbers once I run my test again.

- Matt

On Tue, Aug 2, 2011 at 8:32 PM, Eric Moritz <eric at> wrote:
> Unless you changed R for the bucket, the default that ships with Riak
> is 2.  It's actually "n_val / 2 + 1" also known as the quorum
> <>.  n_val is 3 by
> default resulting in R=2.
> Eric.
> On Tue, Aug 2, 2011 at 8:11 PM, Matt Savona <matt.savona at> wrote:
>> Hi Eric,
>> I this test, R=1 (the default).
>> Thanks!
>> - Matt
>> On Tue, Aug 2, 2011 at 4:35 PM, Eric Moritz <eric at> wrote:
>>> When you were doing the reads, did you set the r-value to 1?  This
>>> will speed up reads in a read heavy app because only one node has to
>>> be in agreement about the object.
>>> Eric.
>>> On Tue, Aug 2, 2011 at 11:22 AM, Matt Savona <matt.savona at> wrote:
>>>> Hi all,
>>>> My colleagues and I are evaluating Riak as a persistent, replicated K-V store.
>>>> I have a fairly simple (and not so scientific) test that reads and
>>>> writes 5000 objects that are 32K in size. I am particularly interested
>>>> in squeezing every last bit of performance out of Riak in a very
>>>> read-heavy environment. I want to avoid hitting disk for reads as much
>>>> as possible; our entire content set is much larger than could ever be
>>>> stored in RAM, but preferably hot/active objects will remain resident
>>>> in memory until various conditions may force them to be evicted. While
>>>> the content set is quite large, the number of active keys represent a
>>>> very small portion of the data which could easily fit in RAM.
>>>> I've been running the same test against Riak given various
>>>> combinations of backends and access protocols (HTTP vs. PB).
>>>> My numbers can be seen in this screenshot:
>>>> It is quite evident (and perhaps obvious) that Protocol Buffer
>>>> performance is noticeably better than HTTP in most cases.
>>>> What is confusing to me is the performance of purely in-memory
>>>> backends. Notably, GB Trees and LRU Cache (and even Innostore), at
>>>> best took 14s to retrieve 5000 32K objects. The exact same test
>>>> against Membase took just 6s.
>>>> Perhaps I'm not comparing apples to apples (Riak in-memory versus
>>>> Membase). Do my tests look reasonable and do the numbers look roughly
>>>> in-line with expectations? Is there any way to squeeze more juice out
>>>> of Riak? A purely in-memory/non-persistent backend will not suffice
>>>> for our ultimate needs, but for testing purposes I'm just trying to
>>>> see if I can get read performance more in line with what we're seeing
>>>> with Membase. We love everything about it, but we haven't yet hit the
>>>> performance we were hoping for.
>>>> Thanks in advance!
>>>> - Matt
>>>> _______________________________________________
>>>> riak-users mailing list
>>>> riak-users at

More information about the riak-users mailing list