[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-user
Subject: Re: increased RF and repair, not working?
From: Tamar Fraenkel <tamar () tok-media ! com>
Date: 2012-07-30 14:46:14
Message-ID: CABZP+MTX=7Zce=DhBF34McKs3P9K6ugK2ZdA1va-ArJo1jCeQA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks!
*Tamar Fraenkel *
Senior Software Engineer, TOK Media
[image: Inline image 1]
tamar@tok-media.com
Tel: +972 2 6409736
Mob: +972 54 8356490
Fax: +972 2 5612956
On Mon, Jul 30, 2012 at 5:30 PM, Tim Wintle <timwintle@gmail.com> wrote:
>
> On Mon, 2012-07-30 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@tok-media.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, 2012-07-30 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
> >
> >
> > >
> > >
> >
> >
> >
> >
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Thanks!<br clear="all"><div dir="ltr"><div dir="ltr"><b><span \
class="GingerNoCheckStart"></span>Tamar Fraenkel </b><br>Senior Software Engineer, \
TOK Media <br><br><div dir="ltr"><img src="cid:ii_135b91fb888fa9ff" alt="Inline image \
1"><br>
<div><br><a href="mailto:tamar@tok-media.com" \
target="_blank">tamar@tok-media.com</a><br>Tel: <a value="+97226409736">+972 2 \
6409736</a> <br>Mob: <a value="+972548356490">+972 54 8356490</a> <br>Fax: <a \
value="+97225612956">+972 2 5612956</a> </div>
</div><br></div><br></div><br>
<br><br><div class="gmail_quote">On Mon, Jul 30, 2012 at 5:30 PM, Tim Wintle <span \
dir="ltr"><<a href="mailto:timwintle@gmail.com" \
target="_blank">timwintle@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div class="im"><br>
On Mon, 2012-07-30 at 15:16 +0300, Tamar Fraenkel wrote:<br>
> How do you make this calculation?<br>
<br>
</div>It seems I did make a mistake somewhere before (or I mistyped it) - it<br>
should have been 2.7%, not 2.8%.<br>
<br>
<br>
You're sending read requests to RF servers, and hoping for a response<br>
from CL of them within the time.<br>
<br>
For N=2, CL=1 - the probability of both hitting the worst 10% latency is<br>
0.1 * 0.1 = 1%<br>
<br>
For N=3, C=2 - the probability of two of the three servers hitting the<br>
worst 10% latency is (0.9 * (0.1 * 0.1) ) + (0.1 * ((0.1 * 0.9) + (0.9 *<br>
0.1))) = 2.7%<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Tim<br>
</font></span><div class="im HOEnZb"><br>
<br>
<br>
<br>
><br>
> Thanks,<br>
> Tamar Fraenkel<br>
> Senior Software Engineer, TOK Media<br>
><br>
</div><div class="HOEnZb"><div class="h5">> Inline image 1<br>
><br>
> <a href="mailto:tamar@tok-media.com">tamar@tok-media.com</a><br>
> Tel: <a href="tel:%2B972%202%206409736" value="+97226409736">+972 2 \
6409736</a><br> > Mob: <a href="tel:%2B972%2054%208356490" \
value="+972548356490">+972 54 8356490</a><br> > Fax: <a \
href="tel:%2B972%202%205612956" value="+97225612956">+972 2 5612956</a><br> <br>
><br>
<br>
><br>
> On Mon, Jul 30, 2012 at 3:14 PM, Tim Wintle <<a \
href="mailto:timwintle@gmail.com">timwintle@gmail.com</a>><br> > wrote:<br>
> On Mon, 2012-07-30 at 14:40 +0300, Tamar Fraenkel wrote:<br>
> > Hi!<br>
> > To clarify it a bit more,<br>
> > Let's assume the setup is changed to<br>
> > RF=3<br>
> > W_CL=QUORUM (or two for that matter)<br>
> > R_CL=ONE<br>
><br>
> > The setup will now work for both read and write in case of<br>
> one node<br>
> > failure.<br>
> > What are the disadvantages, other than the disk space needed<br>
> to<br>
> > replicate everything trice instead of twice? Will it affect<br>
> also<br>
> > performance?<br>
><br>
><br>
> (I'm also running RF2, W_CL1, R_CL1 atm - so this is<br>
> theoretical)<br>
><br>
> As I understand it, the most significant performance hit will<br>
> be to the<br>
> variation in response time.<br>
><br>
> For example with R_CL1, (roughly) 1% of requests will be take<br>
> more than<br>
> the worst 10% of server response times. With R_CL=QUORUM 2.8%<br>
> of<br>
> requests will have the same latency. (assuming I've just<br>
> calculated that<br>
> right)<br>
><br>
> Tim<br>
><br>
><br>
> ><br>
> ><br>
><br>
><br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><span class="GingerNoCheckEnd"></span><br></div>
--f46d04182658d56f5d04c60d20cf--
["tokLogo.png" (image/png)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic