[
https://issues.apache.org/jira/browse/HBASE-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15136622#comment-15136622
]
stack commented on HBASE-15158:
-------------------------------
Ran simple compare of a few ycsb workloads on master comparing unpatched and
patched where each workload ran for an hour on a 9 node cluster
h2. Loading
h3. UNPATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 8349.441142540698
{code}
h3. PATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 8636.35397635922
{code}
h2. Workloada 50%/50%
h3. UNPATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 23114.110426725238
"metric" : "READ",
"measurement" : "Operations",
"value" : 4.167749E7
"metric" : "UPDATE",
"measurement" : "Operations",
"value" : 4.165676E7
{code}
h3. PATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 24415.79341421144
"metric" : "READ",
"measurement" : "Operations",
"value" : 4.4031342E7
"metric" : "UPDATE",
"measurement" : "Operations",
"value" : 4.4018113E7
{code}
h2. workloadb 95% read
h3. UNPATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 47185.40583453721
{code}
h3. PATCHED
{code}
"metric" : "OVERALL",
"measurement" : "Throughput(ops/sec)",
"value" : 55946.36692454564
{code}
h2. workload2 80% writes
Something wrong here. PATCHED seems way too good (I wasn't watching it)
Let me upload the measurements.
Going to apply the patch to master.
> Change order in which we do write pipeline operations; do all under row locks!
> ------------------------------------------------------------------------------
>
> Key: HBASE-15158
> URL: https://issues.apache.org/jira/browse/HBASE-15158
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0
>
> Attachments: 15158.patch, 15158v2.patch, 15158v3.patch,
> 15158v4.patch, 15158v4.patch
>
>
> Change how we do our write pipeline. I want to do all write pipeline ops
> under row lock so I lean on this fact fixing performance regression in
> check-and-set type operations like increment, append, and checkAnd* (see
> sibling issue HBASE-15082).
> To be specific, we write like this now:
> {code}
> # take rowlock
> # start mvcc
> # append to WAL
> # add to memstore
> # let go of rowlock
> # sync WAL
> # in case of error: rollback memstore
> {code}
> Instead, write like this:
> {code}
> # take rowlock
> # start mvcc
> # append to WAL
> # sync WAL
> # add to memstore
> # let go of rowlock
> ... no need to do rollback.
> {code}
> The old ordering was put in place because it got better performance in a time
> when WAL was different and before row locks were read/write (HBASE-12751).
> Testing in branch-1 shows that a reordering and skipping mvcc waits gets us
> back to the performance we had before we unified mvcc and sequenceid
> (HBASE-8763). Tests in HBASE-15046 show that at the macro level using our
> usual perf tools, reordering pipeline seems to cause no slowdown (see
> HBASE-15046). A rough compare of increments with reordered write pipeline
> seems to have us getting back a bunch of our performance (see tail of
> https://issues.apache.org/jira/browse/HBASE-15082?focusedCommentId=15111703&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15111703
> and subsequent comment).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
