[ https://issues.apache.org/jira/browse/GEODE-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834071#comment-16834071 ]
Darrel Schneider commented on GEODE-6663: ----------------------------------------- I made a pretty simple change in: 0430cf6d80c6398b57ac08002692369557760da7 that causes the direct ByteBuffer that is used in readAck to have a minimum size of: getConduit().tcpBufferSize when NioPlainEngine is created. It also consistently sets the receive buffer in Connection to this size instead of trying to optimize it by having it be SMALL_BUFFER_SIZE. With those two changes I no longer saw small direct ByteBuffers getting managed by the Buffers class. > conserve-sockets=false can cause buffer fragmentation > ----------------------------------------------------- > > Key: GEODE-6663 > URL: https://issues.apache.org/jira/browse/GEODE-6663 > Project: Geode > Issue Type: Bug > Components: messaging > Reporter: Darrel Schneider > Priority: Major > Labels: performance > > When conserve-sockets is set to false it enables an optimization called > direct ack. This optimization allows the reply message to be sent directly > back to the requestor on the same socket it sent to request. But the way the > reply is read (see Connection.readAck) can cause small direct ByteBuffer > instances to be created and added to the queue in the Buffers class. These > small buffers can then cause future allocations from the queue to be slower > because the small ones are removed and and added back to the end of the queue. > I think it would be better for readAck to allocate one of this fixed size: > "this.owner.getConduit().tcpBufferSize" instead of basing it off of the reply > message size. > That would keep the all the ones in Buffers the same size. > It is possible that the "inputBuffer" owned by Connection could be used. But > Bruce had this warning regard it: "Be careful about using the Connection's > input buffer. I had so much trouble with multi-threaded access to that > buffer that I decided not to use it in MsgReader." -- This message was sent by Atlassian JIRA (v7.6.3#76005)