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 <[email protected]> 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 > <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 <[email protected]> wrote: >> Hi Eric, >> >> I this test, R=1 (the default). >> >> Thanks! >> >> - Matt >> >> On Tue, Aug 2, 2011 at 4:35 PM, Eric Moritz <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>> >>> >> > _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
