[ https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16441396#comment-16441396 ]
stack commented on HBASE-20188: ------------------------------- I added another sheet to the report (Truncate 04/17). It provides detail on summary given above, that hbase2 -- when the table is truncated when we go from 1.2.7 to 2.0.0 runs -- is a good bit faster reading but still slower when pure reads. In this default YCSB hbase2 is good enough for now. There is a bunch we can do to optimize but no easy win after study; will require effort. As per an off-list comment by [~ram_krish], indeed, the YCSB default is no client-side batching -- see below where payload is 1.7k though we are set to use bufferedmutator. Let me try PE, the tool [~anoop.hbase] has been using. It does batching. {code} 501411 2018-04-17 11:07:34,037 TRACE [RpcServer.default.FPBQ.Fifo.handler=46,queue=1,port=16020] ipc.RpcServer: callId: 2477247 service: ClientService methodName: Multi size: 1.7 K connection: 10.17.240.20:58304 deadline: 9223372036854775807 param: region= ycsb,user5139312943861817391, 1523988283780.8a9442655986021253d3acc69dde60df., for 1 actions and 1st row key=user6571173983002699380 connection: 10.17.240.20:58304, response regionActionResult { resultOrException { index: 0 result { } } } regionStatistics { } queueTime: 0 processingTime: 6 totalTime: 6 {code} > [TESTING] Performance > --------------------- > > Key: HBASE-20188 > URL: https://issues.apache.org/jira/browse/HBASE-20188 > Project: HBase > Issue Type: Umbrella > Components: Performance > Reporter: stack > Assignee: stack > Priority: Blocker > Fix For: 2.0.0 > > Attachments: CAM-CONFIG-V01.patch, HBASE-20188-xac.sh, > HBASE-20188.sh, HBase 2.0 performance evaluation - 8GB(1).pdf, HBase 2.0 > performance evaluation - 8GB.pdf, HBase 2.0 performance evaluation - Basic vs > None_ system settings.pdf, ITBLL2.5B_1.2.7vs2.0.0_cpu.png, > ITBLL2.5B_1.2.7vs2.0.0_gctime.png, ITBLL2.5B_1.2.7vs2.0.0_iops.png, > ITBLL2.5B_1.2.7vs2.0.0_load.png, ITBLL2.5B_1.2.7vs2.0.0_memheap.png, > ITBLL2.5B_1.2.7vs2.0.0_memstore.png, ITBLL2.5B_1.2.7vs2.0.0_ops.png, > ITBLL2.5B_1.2.7vs2.0.0_ops_NOT_summing_regions.png, YCSB_CPU.png, > YCSB_GC_TIME.png, YCSB_IN_MEMORY_COMPACTION=NONE.ops.png, YCSB_MEMSTORE.png, > YCSB_OPs.png, YCSB_in-memory-compaction=NONE.ops.png, YCSB_load.png, > flamegraph-1072.1.svg, flamegraph-1072.2.svg, hbase-env.sh, hbase-site.xml, > hbase-site.xml, hits.png, lock.127.workloadc.20180402T200918Z.svg, > lock.2.memsize2.c.20180403T160257Z.svg, perregion.png, run_ycsb.sh, > total.png, tree.txt, workloadx, workloadx > > > How does 2.0.0 compare to old versions? Is it faster, slower? There is rumor > that it is much slower, that the problem is the asyncwal writing. Does > in-memory compaction slow us down or speed us up? What happens when you > enable offheaping? > Keep notes here in this umbrella issue. Need to be able to say something > about perf when 2.0.0 ships. -- This message was sent by Atlassian JIRA (v7.6.3#76005)