On 24/05/07, Jeanfrancois Arcand <Jeanfrancois.Arcand_at_sun.com> wrote:
> The slides were just posted from this Java One session claiming Grizzly
> blows MINA away performance-wise, and I'm just curious as to people's views
> on it. They present some interesting ideas about optimizing selector
> threading and ByteBuffer use.
Hi,
This topic is one I am very interested in. Apologies in advance for
this rather long post.
I am one of the original developers of what is now Apache Qpid, the
message broker that implements the AMQP protocol.
When I started building Qpid, which was around two years ago Grizzly
was not available (at least I don't think it was) and I picked MINA
really as a way of simplifying development in the early stages. Once
it developed beyond a prototype, performance became more important
(particularly since we originally targetted high performance transient
pub/sub messaging) and we did quite a lot of work to analyse the
performance and tune it. A lot of that tuning was not surprisingly in
MINA.
When I heard about grizzly while on a visit to Burlington I intended
to do some comparative tests between it and MINA but my involvement in
Qpid has reduced significantly and I have no longer had much time to
devote to that task for various reasons. Having said that, I am very
interested in the Grizzly team's opinion on the MINA-based
architecture we use in Qpid. The MINA architecture has always slightly
intrigued me since it does not match anything I have read in books or
papers (although that could simply be my ignorance).
I should state that the benchmarking I did with Qpid showed that it
had very good performance compared with other message brokers. We did
have to tweak MINA because of several characteristics we found
undesirable (which we did submit to the MINA team although I believe
they chose not to implement them all so the current MINA release
probably does not match what is used by Qpid).
This page:
http://cwiki.apache.org/confluence/display/qpid/Qpid+Design+-+Threading
shows the Qpid threading model which also includes MINA. It is
slightly out of date as I describe below but is accurate in the main
aspects.
The key bit that I haven't seen other I/O frameworks adopting is the
SocketIOProcessor. In MINA, each connection is assigned a socket io
processor (on a round robin basis, typically we have one socket io
processor per CPU core), which is responsible for polling each socket
and reading data up to the configured size of the read buffer, before
handing this off to another thread pool. In Qpid, we changed this so
that each socket io processor is split into a read thread and a write
thread so that we can do concurrent reads and writes on a given socket
(not shown in the diagram). This approach is to me very different from
the leader-follower model described in so many texts.
Does anyone have any insights into how this might compare with other approaches?
Are there any further details on the performance tests that were run?
A message broker has certainly got very different characteristics to
an HTTP server (e.g. far fewer but much longer connections) plus AMQP
is designed so you always know exactly how many bytes you need to read
off the wire to complete a "command".
Are there any message brokers implementations on top of Grizzly?
Thanks for reading,
Robert