On 5/30/07, Lee Carlson <[EMAIL PROTECTED]> wrote:
Mina developers-
During some profiling of my TCP/UDP NIO layer I've been working on,
you'll find it as no suprise that the ByteBuffer.allocate() was
taking more time than any other method by a large margin (sorry I
don't have specifics). I looked at using composition to wrap a
ByteBuffer with functionality such as the "release()" method of the
mina bytebuffer pool, but it would require method signatures to be
changed, and had to be handled carefully or memory leaks could occur.
I looked at the technique of allocating a big (4MB+) ByteBuffer and
then issuing slices but didn't really see a performance boost from
this, and it didn't reuse the buffers.
We found heap buffers perform better without a buffer pool, and
concluded that we don't need a buffer pool for direct buffers either
because JVM will do the pooling for us. Consequently, we removed
acquire() and release() in our trunk (2.0.0-M1-SNAPSHOT). We saw
performance improvement thanks to the change.
You will also need to check the default receive/send buffer size of
your operating system. If it's too big, decreasing them to more
reasonable value such as 1024. I experienced huge performance boost
just by changing the buffer size.
Please let me know if your approach performs still better than what I suggest:
1) Adjust the socket receive/send buffer size.
2) Use heap buffers only.
3) Change ByteBufferAllocator: ByteBuffer.setAllocator(new
SimpleByteBufferAllocator());
Thanks and HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
