On Apr 28, 2006, at 6:33 AM, [EMAIL PROTECTED] wrote:
During the analysis, we had a problem on all JVMs where we were running out of native memory (i.e. we were allocating too many direct buffers). This was in fact a memory leak in our application, but during the testing, I modified MINA so that it would always allocate heap buffers (never direct). All the documentation indicates that you should use direct buffers for I/O, but when we used heap buffers we found that the performance improved significantly! On one of our tests the performance doubled on JRockit, and on others it increased by at least 20%.
I was just re-reading the docs on ByteBuffer, and on JDK5, they state "In general it is best to allocate direct buffers only when they yield a measureable gain in program performance." .. so I'd say that jives with what you've seen.
We also found that, when using heap buffers, using the Pooled allocator was slower than the simple allocator - i.e. allowing the JVM to allocate buffers was more efficient.
Not surprising. I've removed the pooling of the PooledByteBuffer wrappers in my development branch since I saw the synchronization of returning them to the pool to be a hotspot. Since they're just wrapper objects, pooling isn't really necessary.
[As a side issue I am about to raise an issue to add dispose() to the Allocator interface - currently if you set the allocator the pooled allocator expirer thread still runs].
done!
I should point out that we found 32k send and receive buffers offered significant improvements compared with e.g. 8k.
Were you looking for throughput over latency or vice versa? Just wondering if you had toggled TCP_NODELAY at all in your testing.
What was the impact on the Sun JVM? Well, the Sun JVM suffers an as yet unexplained warm up period where the first batch on traffic on our test would take seven times longer than subsequent batches.
interesting. how long of a warmup period?
Comments most welcome! If our analysis with Sun comes up with anything to explain the initial spike in the Sun JVM performance I'll let you know.
Thanks for sharing, and do keep us updated! -pete -- [EMAIL PROTECTED] - http://fotap.org/~osi
smime.p7s
Description: S/MIME cryptographic signature
