[
https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15046:
--------------------------
Attachment: call_times_0-1_and_1-3_ycsb.png
Here is run of a suite of ycsb tests (30 threads to a single regionserver):
load workload a, run workload a (50/50), then workload b (95 read/5 write), c
(100 read), f (50 read/50 read modify write). Graphs are about same for both
patched and unpatched dominibatch.... The pure writes and reads seem to be
slightly faster ... not sure why reads would be faster but 95/5 seems a tad
slower (in middle is an aborted run -- the patch seems to bring on mvcc
lockup... need to look into that). Let me keep going down this path.... will
try some more intense runs meantime.
> 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
> Attachments: 1.2.svg, 1.2.v2.svg, all_under_lock.patch,
> all_under_lock.svg, call_times_0-1_and_1-3_ycsb.png, latencies.png, 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)
