Le vendredi 17 novembre 2006 à 22:17 +0900, Trustin Lee a écrit : > Hi, > > I ran some performance test with the following settings: > > * Direct buffer with PooledByteBufferAllocator > * Heap buffer with PooledByteBufferAllocator > * Heap buffer with SimpleByteBufferAllocator > > PooledByteBufferAllocator is the default allocator that MINA uses to > allocate ByteBuffers. It pools all buffers created by itself. When a user > calls ByteBuffer.release(), it is returned to the pool. MINA is implemented > to release the buffer automatically for a few obvious case as specified in > JavaDoc. The reason why I introduced the pool and acquire/release() methods > is because direct buffers take long time to be allocated. By using buffer > pooling, we were able to save time to allocate direct ByteBuffers. The > disadvantage of this allocator is that there's synchronization cost during > acquire() or release() is invoked. It might prevent multi-processor > machines from performing better than we expected. > > SimpleByteAllocator is a very simple allocator. It just creates a new > ByteBuffer whenever requested. It never pools anything. The advantage of > this allocator is that it doesn't have any synchronization cost. It just > allocates a buffer and forget about it. This works best with heap byte > buffers because the time complexity of Java heap memory allocation is O(1), > fantastic constant time. > > We usually have been taught that direct buffers will perform better than > heap buffers, but many performance test results including mine are saying > that heap buffers are performing *far* better. I got almost 50% performance > boost after switching from direct buffer with PooledByteBufferAllocator to > heap buffer with SimpleByteBufferAllocator. Is there anyone who had similar > experiences? > > In this context, I think the value of the default buffer pooling that MINA > provides might be dubious. If this is true, should we have to have > acquire() and release() methods sacrificing API usability? Why don't we > just get rid of (or deprecate) them and let the VM take care of the whole > buffer management? > > Trustin > > PS: I beat Apache HTTP 2.0.55 with MINA + AsyncWeb today. I was able to get > 20,000 msg/sec throughput with my dual core opteron dual box. I will give > you an update later when more data is gathered and feel confident that I > configured Apache HTTPD to its maximum performance.
Without the big buffer pool it will prolly improve the memory footprint of MINA apps. Actualy the default pool of buffer can be a memory hog, even without intensive I/O. For the API compatibility issue, kill the method in 2.0 and tag as deprecated in next release. BTW there is a point in keeping the possibility of using direct buffers ? Julien
