[
https://issues.apache.org/jira/browse/HBASE-13819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16281355#comment-16281355
]
Anoop Sam John commented on HBASE-13819:
----------------------------------------
So u mean the NIO wont keep that DBB in its ThreadLocal based pool. Good.. I
believe it pools latest 5 DBBs or so. Somewhere saw this number. Means we can
have a way to say max how many DBB size can get pooled . But that is in
ThreadLocal means we have to * this number with max handlers counts. So that
will give what max DBB the NIO layer can hold.
The BBPool of ours is bit diff BTW. The DBBs are all fixed sized. There wont
be creation of any random sized DBB and pool that. Ya that was the case in
older impl in 1.x. There we had some max size for the BB which can be pooled.
In 2.0 it is simpler. All DBBs are fixed size and we have a max #DBBs to pool
also. So we know the max size the BBPool can grow. When request comes, we
read that into one more MORE DBBs as per the req size. That way we avoid random
sized DBB create. Only when the req pace is more and we are out of DBBs in
pool, we will end up making use of the NIO way of random DBB create. Because
when we can not see a free DBB from pool (to read reqs into), we will make on
demand on heap BB and pass that to NIO.
Ya Netty am also try to learn fully abt these aspects.
> Make RPC layer CellBlock buffer a DirectByteBuffer
> --------------------------------------------------
>
> Key: HBASE-13819
> URL: https://issues.apache.org/jira/browse/HBASE-13819
> Project: HBase
> Issue Type: Sub-task
> Components: Scanners
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13819.patch, HBASE-13819_branch-1.patch,
> HBASE-13819_branch-1.patch, HBASE-13819_branch-1.patch, q.png
>
>
> In RPC layer, when we make a cellBlock to put as RPC payload, we will make an
> on heap byte buffer (via BoundedByteBufferPool). The pool will keep upto
> certain number of buffers. This jira aims at testing possibility for making
> this buffers off heap ones. (DBB) The advantages
> 1. Unsafe based writes to off heap is faster than that to on heap. Now we are
> not using unsafe based writes at all. Even if we add, DBB will be better
> 2. When Cells are backed by off heap (HBASE-11425) off heap to off heap
> writes will be better
> 3. When checked the code in SocketChannel impl, if we pass a HeapByteBuffer
> to the socket channel, it will create a temp DBB and copy data to there and
> only DBBs will be moved to Sockets. If we make DBB 1st hand itself, we can
> avoid this one more level of copying.
> Will do different perf testing with changed and report back.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
