e
> > > optimization?
> > > Depending upon the table size you can also look into caching the table
> or
> > > not caching at all.
> > >
> > > -Original Message-
> > > From: hongbin ma [mailto:mahong...@apache.org]
> > &g
hbase.apache.org
Cc: Thakrar, Jayesh <jthak...@conversantmedia.com>
Subject: Re: Rows per second for RegionScanner
Try disabling block encoding - you will get better numbers.
>> I mean per region scan speed,
Scan performance depends on # of CPU cores, the more cores you have the more
perfo
t; > You can read up on it - https://hbase.apache.org/book.html
> >
> > Another thing, are you just looking for pure scan-read performance
> > optimization?
> > Depending upon the table size you can also look into caching the table or
> > not caching at all.
> >
> &
t; From: hongbin ma [mailto:mahong...@apache.org]
> Sent: Thursday, April 21, 2016 5:04 AM
> To: user@hbase.apache.org
> Subject: Rows per second for RegionScanner
>
> Hi, experts,
>
> I'm trying to figure out how fast hbase can scan. I'm setting up the
> RegionScan in a endpoin
optimization?
Depending upon the table size you can also look into caching the table or not
caching at all.
-Original Message-
From: hongbin ma [mailto:mahong...@apache.org]
Sent: Thursday, April 21, 2016 5:04 AM
To: user@hbase.apache.org
Subject: Rows per second for RegionScanner
Hi
Hi, experts,
I'm trying to figure out how fast hbase can scan. I'm setting up the
RegionScan in a endpoint coprocessor so that no network overhead will be
included. My average key length is 35 and average value length is 5.
My test result is that if I warm all my interested blocks in the block
