[ 
https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

stack resolved HBASE-15046.
---------------------------
       Resolution: Fixed
    Fix Version/s: 2.0.0
     Release Note: In here we perf tested a realignment of the write pipeline 
and mvcc handling.  Thought was that this work was a predicate for a general 
fix of HBASE-14460 (turns out, realignment of write path was not needed to fix 
the increment perf regression). The perf testing here made it so we were able 
to simplify writing. HBASE-15158 was just committed. This work is done.

> Perf test doing all mutation steps under row lock
> -------------------------------------------------
>
>                 Key: HBASE-15046
>                 URL: https://issues.apache.org/jira/browse/HBASE-15046
>             Project: HBase
>          Issue Type: Sub-task
>          Components: Performance
>            Reporter: stack
>            Assignee: stack
>             Fix For: 2.0.0
>
>         Attachments: 1.2.svg, 1.2.v2.svg, 50threads_ycsb.png, 
> all_under_lock.patch, all_under_lock.svg, call_times_0-1_and_1-3_ycsb.png, 
> compare.png, gc.png, latencies.png, nopatch.png, 
> notpatched.workloadw.80percentwrites.json, ops.png, patched.png, 
> patched.workloadw.80percentwrites.json, writes.png
>
>
> This issue is about perf testing a redo of the write pipeline so that rather 
> than:
> * take rowlock
> * start mvcc
> * append to WAL
> * add to memstore
> * sync WAL
> * let go of rowlock
> * finish up mvcc
> instead.... try...
> * take rowlock
> * start mvcc
> * append to WAL
> * sync WAL
> * add to memstore
> * finish up mvcc
> * let go of rowlock
> The latter is more straight-forward undoing need of rolling back memstore if 
> all does not succeed.
> It might be slower though. This issue is a look-see/try it.
> The redo will also help address the parent issue in a more general way so we 
> can do without the special-casing done for branch-1.0 and branch-1.1 done in 
> a sibling subtask.
> Other benefits are that the current write pipeline is copy/pasted in a few 
> places  -- in append, increment and checkand* -- and a refactor will allow us 
> to fix this duplication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to