On Mon, 20120730 at 15:16 +0300, Tamar Fraenkel wrote:
> How do you make this calculation?
It seems I did make a mistake somewhere before (or I mistyped it)  it
should have been 2.7%, not 2.8%.
You're sending read requests to RF servers, and hoping for a response
from CL of them within the time.
For N=2, CL=1  the probability of both hitting the worst 10% latency is
0.1 * 0.1 = 1%
For N=3, C=2  the probability of two of the three servers hitting the
worst 10% latency is (0.9 * (0.1 * 0.1) ) + (0.1 * ((0.1 * 0.9) + (0.9 *
0.1))) = 2.7%
Tim
>
> Thanks,
> Tamar Fraenkel
> Senior Software Engineer, TOK Media
>
> Inline image 1
>
> tamar@tokmedia.com
> Tel: +972 2 6409736
> Mob: +972 54 8356490
> Fax: +972 2 5612956
>
>
> On Mon, Jul 30, 2012 at 3:14 PM, Tim Wintle <timwintle@gmail.com>
> wrote:
> On Mon, 20120730 at 14:40 +0300, Tamar Fraenkel wrote:
> > Hi!
> > To clarify it a bit more,
> > Let's assume the setup is changed to
> > RF=3
> > W_CL=QUORUM (or two for that matter)
> > R_CL=ONE
>
> > The setup will now work for both read and write in case of
> one node
> > failure.
> > What are the disadvantages, other than the disk space needed
> to
> > replicate everything trice instead of twice? Will it affect
> also
> > performance?
>
>
> (I'm also running RF2, W_CL1, R_CL1 atm  so this is
> theoretical)
>
> As I understand it, the most significant performance hit will
> be to the
> variation in response time.
>
> For example with R_CL1, (roughly) 1% of requests will be take
> more than
> the worst 10% of server response times. With R_CL=QUORUM 2.8%
> of
> requests will have the same latency. (assuming I've just
> calculated that
> right)
>
> Tim
>
>
> >
> >
>
>
>
>
