It does beg the question - in which cases would using direct buffers yield a measurable gain in program performance? The javadoc does say in the sentence before the one you quote:
"It is therefore recommended that direct buffers be allocated primarily for large, long-lived buffers that are subject to the underlying system's native I/O operations."
I suppose it doesn't define "large" though.
Re latency versus thoughput, we are trying to strike a good balance. (We currently see latency of around 0.2ms which is good enough for our application). We have disabled Nagle, and I would rather build some intelligence into flushing rather than using Nagle.
The "warmup" period sees the initial test batch taking about 7 seconds rather than 800ms to complete. On JDK 1.5 it is about 4 seconds and on IBM JDK it is > 8 seconds.
Robert
| peter royal <[EMAIL PROTECTED]>
28/04/2006 19:17
|
To: [email protected] cc: Subject: Re: Performance - some interesting results |
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
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
