This test targets the client and the communication layers of HBase. It uses a coprocessor that keeps the region empty (HBASE-10001), and all the internal layers (memstore, cache, ...) are skipped. The region server and the client are run on the same machine, this way we're not limited by the network. What remains when there is no disk i/o not network i/o is the cpu, and, indeed, that's the issue. Protobuf comes with a lot of object creations and array copies. The difference between the 0.96 and the .96 head comes from the removal of many of these copies / creations. The remaining gap with 0.94 could come from the remaining array copies, that's what I'm looking at right now.
This test has some specificities: - it uses YCSB: YCSB does puts of 1KB size which can be small or large, depending on your own use case. Smaller would mean that the cost of the array copies is less important. - there no network nor disk. Usually the disk i/o are the bottleneck. - the data is not inserted in HBase: the memstore stays empty, we don't write on HDFS (WAL or flush or compactions). The gets are done on an empty table. - there is a single region server, so by definition it gets all the load. It maximizes the visibility of any GC on the server. - the client and the region are on the same machine, so they are struggling for the CPU. YCSB uses quite a lot of CPU resources as well. So it's a development test to highlight a specific problem, not a real benchmark. Cheers, Nicolas On Tue, Nov 26, 2013 at 6:31 AM, lars hofhansl <[email protected]> wrote: > As a general comment for 0.94 vs 0.96 testing... Please always make sure > we are testing against the same default options. > > In 0.96 we increased the default blockCache, enabled scanner caching, > disabled Nagle's, increased the handler count, etc. > In order to compare apples to apples we should always add the following > config options to 0.94 (in hbase-site.xml) > > hbase.regionserver.global.memstore.lowerLimit = 0.38 > hfile.block.cache.size = 0.4 > hbase.ipc.client.tcpnodelay = true > hbase.regionserver.handler.count = 30 > hbase.client.scanner.caching = 100 > > There might be more, but these are obvious ones. > > Thanks. > > -- Lars > > > > > ________________________________ > From: Jerry He <[email protected]> > To: dev <[email protected]> > Sent: Monday, November 25, 2013 2:09 PM > Subject: Re: HBase 0.96.0 performace > > > Hi, Ted > > Do you have the slides? > I don't have the full slides. The image was passed to me by a co-worker in > China. We are evaluating it. > I am copying the numbers below: > > Release 3 YCSB clients (puts/seconds) 5 YCSB clients > (puts/seconds) > 0.94.14 178K 220K > 0.96.0 20K 15K > 0.96.1 173K 168K > > Release 10 YCSB clients (reads/seconds) 25 YCSB clients > (reads/seconds) > 0.94.14 50K 52K > 0.96.0 23K 23K > 0.96.1 52K 54K > > > > On Mon, Nov 25, 2013 at 1:25 PM, Ted Yu <[email protected]> wrote: > > > Jerry: > > Where did you obtain the picture ? > > > > If you got it from slides posted on China Hadoop Summit website, can you > > share the link ? > > > > Cheers > > > > > > On Tue, Nov 26, 2013 at 3:55 AM, Ted Yu <[email protected]> wrote: > > > > > The picture didn't go through. > > > > > > Correction: the comparison between hbase 0.96.0 and 0.96.1 was done by > > > Nicolas Liochon. This was not done at EBay. > > > > > > In my talk, there was another comparison to show that MTTR improved a > lot > > > from 0.94 to 0.96 - this was done at EBay. > > > > > > When Stack cuts 0.96.1 RC0, you would get the list of JIRAs that > > > contributed to the speedup from 0.96.0 to 0.96.1 > > > > > > Cheers > > > > > > > > > On Tue, Nov 26, 2013 at 3:50 AM, Jerry He <[email protected]> wrote: > > > > > >> Hi, Ted, and hbase experts > > >> > > >> Below picture is a performance comparison between hbase 0.96.0 and > > >> 0.96.1, shared by Ted Yu in China Hadoop Summit today. This perf > > testing is > > >> said to be executed on ebay's real cluster. > > >> > > >> It is surprising 0.96.0 is such worse compared to 0.96.1 and even > > >> 0.94.14. Are these numbers official and the performance degradation > > true? > > >> What patch in 0.96.1 fixed this? > > >> > > >> > > >> > > >> > > >> > > > > > >
