[
https://issues.apache.org/jira/browse/HBASE-13307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375417#comment-14375417
]
stack commented on HBASE-13307:
-------------------------------
Sorry [~larsh], my comment above went in after yours.
I have filterAll enabled in my PE test so results are not returned -- is that
what you mean by all filtered at the server (Returning results is a bottle neck
to be looked at -- 5/16ths of CPUs used -- but I got distracted when 14/16ths
of CPUs were used when I did not return results to the client but throughput
only went up 1/3rd).
Tell me about your test rig again. How many clients? How much of machine you
using? Can I try your rig over here?
build 1.7.0_67-b01
bq. Is it possible that the time that was spent in this method is not spent
somewhere else? (I got that a lot when I tried to improve memory barriers)
The attached flame graphs show different character as I mess with method sizes
and then the tangible throughput diff.
If you see no benefit, I can drop this avenue of investigation. The difference
is plain in my little test but if only on my rig it probably not 'real'. As
said in parent issue, looking for bigger wins than this
> Making methods under ScannerV2#next smaller allows them to be inlined gaining
> us 7% more throughput
> ---------------------------------------------------------------------------------------------------
>
> Key: HBASE-13307
> URL: https://issues.apache.org/jira/browse/HBASE-13307
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 1.1.0
>
> Attachments: 13307.txt, traces.8.svg, traces.9.svg
>
>
> See parent issue for patch and evidence.
> I was looking at graphs of our scan and found that methods were 'too big' to
> be inlined (looking at jvm compilation and inlining output flags -- see
> parent for list). Changing method size helped some. Let me commit the
> resultant patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
