[
https://issues.apache.org/jira/browse/HBASE-14490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143897#comment-15143897
]
Anoop Sam John edited comment on HBASE-14490 at 2/12/16 7:53 AM:
-----------------------------------------------------------------
{code}
} finally {
1612 dataLengthBuffer.clear(); // Clean for the next call
1613 reqBufPool.putBuffer(data);
1614 data = null;
1615 }
{code}
We can not put back the buffer to pool here. The req is just given to handlers
for processing. With CellScanners in place, we are not sure whether all Cells
are read out of it yet. We can release only at completeion of the Call. This
was initially proposed for read reqs and now for all read and write.
We need 2 pools for req and response?
FYI Stack, we are working in this area for the write path off heaping.. Will
be doing some perf testing soon.
Correction:
We can release the buffers where the req is read into after
resultPair = this.rpcServer.call(call.service, call.md, call.param,
call.cellScanner,
call.timestamp, this.status);
We have done with the req and we are about to make the response...
was (Author: anoop.hbase):
{code}
} finally {
1612 dataLengthBuffer.clear(); // Clean for the next call
1613 reqBufPool.putBuffer(data);
1614 data = null;
1615 }
{code}
We can not put back the buffer to pool here. The req is just given to handlers
for processing. With CellScanners in place, we are not sure whether all Cells
are read out of it yet. We can release only at completeion of the Call. This
was initially proposed for read reqs and now for all read and write.
We need 2 pools for req and response?
FYI Stack, we are working in this area for the write path off heaping.. Will
be doing some perf testing soon.
> [RpcServer] reuse request read buffer
> -------------------------------------
>
> Key: HBASE-14490
> URL: https://issues.apache.org/jira/browse/HBASE-14490
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC
> Affects Versions: 2.0.0, 1.0.2
> Reporter: Zephyr Guo
> Assignee: Zephyr Guo
> Labels: performance
> Fix For: 2.0.0, 1.0.2
>
> Attachments: 14490.hack.to.1.2.patch, ByteBufferPool.java,
> HBASE-14490-v1.patch, HBASE-14490-v10.patch, HBASE-14490-v11.patch,
> HBASE-14490-v12.patch, HBASE-14490-v2.patch, HBASE-14490-v3.patch,
> HBASE-14490-v4.patch, HBASE-14490-v5.patch, HBASE-14490-v6.patch,
> HBASE-14490-v7.patch, HBASE-14490-v8.patch, HBASE-14490-v9.patch, gc.png,
> hits.png, test-v12-patch
>
>
> Reusing buffer to read request.It's not necessary to every request free
> buffer.The idea of optimization is to reduce the times that allocate
> ByteBuffer.
> *Modification*
> 1. {{saslReadAndProcess}} ,{{processOneRpc}}, {{processUnwrappedData}},
> {{processConnectionHeader}} accept a ByteBuffer instead of byte[].They can
> move {{ByteBuffer.position}} correctly when we have read the data.
> 2. {{processUnwrappedData}} no longer use any extra memory.
> 3. Maintaining a buffer pool in each {{Connection}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
