In-Memory Performance

Eric Moritz eric at
Tue Aug 2 16:35:42 EDT 2011

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.


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