Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of ndimiduk@gmail.com designates
 209.85.220.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CADY20s6DDzpO+nNFRukdN=9nNeNuf98EA74YdBAFcU7_VBVKkA@mail.gmail.com>
References: 
 <CADcMMgF5RdWk8kC+64sVnam+j8TNWjBbv3fhAua=vReqJjtkCg@mail.gmail.com>
 <CADcMMgGCPrM4jBo5sNM_obMFudn7+0jQJSmcOqqQat7uBH6e0A@mail.gmail.com>
 <CADY20s7feE2V9y0TgYLK3ferkwbOf+Q5a0=x+G69pqEnxUuTXA@mail.gmail.com>
 <CANZa=Gv9N3XPJXGyF+wx7sx7ToRe6ib-c315Vuxv8tuvpB9p4g@mail.gmail.com>
 <CADY20s6DDzpO+nNFRukdN=9nNeNuf98EA74YdBAFcU7_VBVKkA@mail.gmail.com>
From: Nick Dimiduk <ndimiduk@gmail.com>
Date: Tue, 15 Apr 2014 10:13:00 -0700
Message-ID: 
 <CANZa=GuAuYKwACdgEZoray71ySy3bdjoPhiG-q=TQgGUhLg8Tg@mail.gmail.com>
Subject: Re: blockcache 101
To: hbase-dev <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=047d7b677d36af734a04f717ea7b

--047d7b677d36af734a04f717ea7b
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 14, 2014 at 10:12 PM, Todd Lipcon <todd@cloudera.com> wrote:

>
> Hmm... in "v2.pdf" here you're looking at different ratios of DB size
> to cache size, but there's also the secondary cache on the system (the
> OS block cache), right?


Yes, this is true.

So when you say only 20GB "memory under management", in fact you're still
> probably getting 100% hit rate on the case where the DB is bigger than RAM,
> right?
>

I can speculate, likely that's true, but I don't know this for certain. At
the moment, the only points of instrumentation in the harness are in the
HBase client. The next steps include pushing down into the RS, DN and
further to then is to the OS itself.

Maybe would be better to have each graph show the different cache
> implementations overlaid, rather than the different ratios overlaid? That
> would better differentiate the scaling behavior of the implementations vs
> each other.


I did experiment with that initially. I found the graphs became dense and
unreadable. I need to spend more time studying Tufti to present all these
data points in a single figure. The data is all included, so please, by all
means have a crack at it. Maybe you'll see something I didn't.

 As you've got it, the results seem somewhat obvious ("as the hit ratio
> gets worse, it gets slower").
>

Yes, that's true. Of interest in this particular experiment was the
relative performance of different caches under identical workloads.

--047d7b677d36af734a04f717ea7b--