Re: Performance - some interesting results

[peter royal <pr...@apache.org>]

On Apr 28, 2006, at 6:33 AM, robert.j.greig@jpmorgan.com 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

-- 
proyal@apache.org - http://fotap.org/~osi