[
https://issues.apache.org/jira/browse/HBASE-13291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482609#comment-14482609
]
stack commented on HBASE-13291:
-------------------------------
bq. Again the tweaked patch also we call getKeyLength()? That is again trying
to do Bytes.toInt().
Come again [~ram_krish]? I don't follow?
bq. Will it be possible to create a Cell which could do the caching of these
values like we did in BB cell ...
We could try it. Was interested in counting how many times say the key length
is reparsed between original read from block and final delivery to the rpc.
What would you guess? (smile).
bq. And for the tags hack, we could add an interface with a hasTags API and
when we construct the KV we could set that.
Sure. Seems to be plenty of flags floating about on whether tags or not. Would
be nice if we could skip parsing them each time.
> Lift the scan ceiling
> ---------------------
>
> Key: HBASE-13291
> URL: https://issues.apache.org/jira/browse/HBASE-13291
> Project: HBase
> Issue Type: Improvement
> Components: Scanners
> Affects Versions: 1.0.0
> Reporter: stack
> Assignee: stack
> Attachments: 13291.hacks.txt, 13291.inlining.txt, Screen Shot
> 2015-03-26 at 12.12.13 PM.png, Screen Shot 2015-03-26 at 3.39.33 PM.png,
> TimeRange.patch, hack_to_bypass_bb.txt, nonBBposAndInineMvccVint.txt, q
> (1).png, scan_no_mvcc_optimized.svg, traces.7.svg, traces.filterall.svg,
> traces.nofilter.svg, traces.small2.svg, traces.smaller.svg
>
>
> Scanning medium sized rows with multiple concurrent scanners exhibits
> interesting 'ceiling' properties. A server runs at about 6.7k ops a second
> using 450% of possible 1600% of CPUs when 4 clients each with 10 threads
> doing scan 1000 rows. If I add '--filterAll' argument (do not return
> results), then we run at 1450% of possible 1600% possible but we do 8k ops a
> second.
> Let me attach flame graphs for two cases. Unfortunately, there is some
> frustrating dark art going on. Let me try figure it... Filing issue in
> meantime to keep score in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
