gistfile1.txt

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> https://wiki.basho.com/display/RIAK/REST+API#RESTAPI-Readobject 

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, http://blog.basho.com/2010/09/16/nosql-performance-in-the-cloud-webinar/, 
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> http://blog.basho.com/assets/joyent_basho_webinar.pdf 

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