[
https://issues.apache.org/jira/browse/HBASE-20188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425066#comment-16425066
]
stack commented on HBASE-20188:
-------------------------------
I added a third sheet name "Short Circuit Reads 25M Run" at [1] with timings
with short-circuit read in place for hbase1 and hbase2. Here are findings:
{quote}
Findings: hbase1.x performs better than 2.x in pure read and pure write modes
(but we are now within 10%). Mixed load (workloada 50/50), hbase2 is better no
matter what combination. FastPath RPC Scheduler, the default for hbase2 is
better than the hbase1 RCP scheduler though it looks ugly in the thread dumps
with all threads seemingly backed up on its Semaphore coordinator. hbase2 uses
more CPU but seems to have a flatter GC profile. in-memory compaction costs.
For load, no-in-memory compaction is 4% slower than hbase1, but with in-memory
compaction, it is 9% slower. For workloada, no-in-memory-compaction is 25%
faster than hbase1 and with in-memory compaction, 17% faster. For workloadc,
with no-in-memory compaction, we are 2% slower. With it, we are 5% slower.
{quote}
1.
https://docs.google.com/spreadsheets/d/1w2NBqAPFthG8Ib4C0pHpLARYpWoIF2Vck2vHZW77zE4/edit#gid=1651250875
> [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.sh, 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,
> lock.127.workloadc.20180402T200918Z.svg,
> lock.2.memsize2.c.20180403T160257Z.svg, tree.txt
>
>
> 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)
