Connecting to a single host vs balancing requests

Sargun Dhillon sargun at
Tue Oct 7 05:49:47 EDT 2014

When you do read / modify / writes, are you also planning on sending
the relevant read through one node only? In that case, your update
latency might suffer if the egress queues of your designated node get
backed up on writes, waiting for a very low cost read query.

You're more likely to get awkward load on riak1, and the vnodes that
that node hosts are going to suffer as a result. Although, you may not
see that in the common case where n=3, and r=quorum, (r=2), but if
another vnode in a preflist is degraded, it's likely to be

There are potential performance benefits given some very specific
workloads where you can sacrifice a node, or alternatively you can
configure Riak not to put any vnodes on that node, but these are
advanced options that are not for the faint of heart.

My question would be why are you doing this?

P.S. The way you asked your question of the list is fine.

On Tue, Oct 7, 2014 at 2:09 AM, Geoff Garbers <geoff at> wrote:
> Hi all.
> Apologies if I'm not using the mailing list correctly - this is the
> first time I'm posting to a mailing list.
> We're in the process of redeveloping our systems using Riak, and will
> be using five nodes initially. Let's call these nodes riak1 through to
> riak5. Our read/write/delete distribution is weighted more towards
> reads than writes, with few deletes (if I have to hazard a guess, I
> would say 60/35/5 read/write/deletes).
> A technical decision has been made to ensure that all writes are sent
> to riak1, and all reads are done from riak2 through riak5. The read
> hosts are selected completely at random.
> Apart from the obvious write availability concern, is there any
> performance benefit or penalty to be had from writing to a specific
> node, and reading from the rest? I haven't been able to perform a test
> on this myself, so any input from the community would be appreciated
> for the time being.
> Thanks in advance,
> Geoff
> _______________________________________________
> riak-users mailing list
> riak-users at

More information about the riak-users mailing list