Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
14:20 <allen> seancribbs: for the best performance, would you recomment replication factor 2?
14:21 <benblack> allen: can you describe your performance needs and how you are
using the system? "best performance" is very context specific
14:22 <allen> I m using the system for key/value storage for random read and
random write, 80%/20%.
14:22 <benblack> what r and w values?
14:23 <allen> user session data it will be.
14:24 <benblack> what r and w values?
14:24 <allen> it would be binary data.
14:24 <benblack> sure, i am asking about the r and w values you will use when calling riak
14:26 <benblack>
14:26 <benblack> r - (read quorum) how many replicas need to agree when retrieving the
object (default is defined by the bucket)
14:26 <benblack> that's the r value i'm asking about
14:28 <allen> r - 1, w -1 for the best formance that i m thinking
14:29 <allen> no 2.. I could sacrifice some consistency
14:29 <benblack> then the n_val won't make much performance difference
14:29 <benblack> i'd recommend leaving it at 3.
14:30 <allen> oh.. really, I thoungt replicating factor, which causes disk IO, may
affect the performance.
14:31 <allen> I had experience that from Cassandra, a different product.
14:31 <benblack> i'd give you the same advice in cassandra
14:32 <benblack> if that was causing you trouble on cassandra, it was either misconfigured
or you were oeprating with insufficient disk i/o available, both of which are sadly common
14:32 <benblack> the defaults are not great
14:33 <seancribbs> right, the main concern is disk space consumption and availability w.r.t.
replication factor
14:33 <seancribbs> if you want to use less space, and can stand outages, lower N
14:35 <allen> u r saying replication is happening asynchronously, it does not affect
performance at all, unless diskIO is very bad?
14:35 <benblack> yes, that is how dynamo systems work
14:35 <benblack> if you were attempting to read or write at higher quorum levels, then you
can see performance degrade
14:36 <benblack> but it is a function of the quorum level requested, generally, not the n_val
14:37 <seancribbs> right - the more replies you wait for, the longer it will take
14:37 <seancribbs> because we ship the whole value
14:37 <allen> what if w=2(hopefully on async. mode), will it be different?
14:37 <benblack> yes, as above
14:38 <benblack> "if you were attempting to read or write at higher quorum levels, then
you can see performance degrade"
14:38 <benblack> if you are going to use w=2, you especially do not want an n_val of 2
14:38 <benblack> any node failure will cause writes to fail for keys on that node
14:38 <benblack> (modulo hinted handoff, i know, shoot me)
14:39 <seancribbs> benblack: have that argument with niemeyer, heh
14:39 <benblack> allen: w=2 will generally be slower than w=1, but that is regardless of n_val.
unless you have a specific reason otherwise, really suggest leaving n_val at 3
14:39 <benblack> seancribbs: ?
14:39 <seancribbs> read log from yesterday ;)
14:39 <benblack> tl;dr
14:39 <seancribbs> exactly
14:39 <benblack> heh
14:39 <benblack> perfect!
14:40 <allen> on this,,
did you use replication factor 3?
14:42 <allen> we are going to use Joyent smartmachine from next monday,
hopefully. Trying to mimic your configuration on that pdf.
14:43 <allen>
14:43 <allen> hope I don't bother you guys.
14:43 <benblack> nope, that's what #riak is for
14:44 <drev1> allen: all the Joyent tests were run with N=3
14:44 <allen> nice, good to know
14:44 <allen> thanks drev1, benblack, seancribbs
14:44 <pharkmillups> allen: i was about to say "drev1" is your guy re: those benchmarks :)
14:48 <allen> thank pharkmillups
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.