[ https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15082733#comment-15082733 ]
Heng Chen edited comment on HBASE-15046 at 1/5/16 9:45 AM: ----------------------------------------------------------- {quote} 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). {quote} Did all read requests happen on the latest inserted rows? what's the requestdistribution param, uniform, zipfian or latest ? was (Author: chenheng): {quote} 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). {quote} Is all read requests happens on latest inserted rows? what's the requestdistribution param, uniform, zipfian or latest ? > 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, 50threads_ycsb.png, > 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)