In-Memory Performance

Eric Moritz eric at themoritzfamily.com
Tue Aug 2 20:32:25 EDT 2011


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
<http://wiki.basho.com/Riak-Glossary.html#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 gmail.com> 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 themoritzfamily.com> 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 gmail.com> 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:
>>> 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
>>>
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>
>>
>




More information about the riak-users mailing list