In-Memory Performance

Matt Savona matt.savona at gmail.com
Tue Aug 2 11:22:36 EDT 2011


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:
http://img824.imageshack.us/img824/3185/riakperformance.png

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




More information about the riak-users mailing list