[rabbitmq-discuss] Channels closed unexpectedly in Java client

Wed Sep 14 13:12:25 BST 2011

Hi Iain,

On Wed, Sep 14, 2011 at 06:47:10AM -0500, Iain Hull wrote:
> > Certainly my testing of ext4 is not favourable. It seems to have very
> > inconsistent performance. That said, if it works for you...
> Ok thanks I will add xfs and jfs to my mix for testing.  Do you still 
> have those results? And are they in a consumable format?  Our ops team
> would be really interested in looking over them as the basis for our own
> testing.

I don't still have them, but I'm sure they'd have been simple enough -
probably just measuring overall performance with something like
MulticastMain (Java client) with various flags or I may have written
some custom tests with the Erlang client - certainly you could just use
MulticastMain with -f persistent -r X and tune X for each file system
until you find the highest point at which the latency doesn't grow,
although you'll need to leave it running for a few mins before you can
be sure it's stable.

That'll just measure the cost of writing msgs to disk, though only some
bits of that writing are actually in the path of the msg - other bits
may be done asynchronously at leisure, though ultimately, all bits are
competing for disk bandwidth, so measuring the rate at which data is
written to disk may be indicative of performance.

You could also try creating a durable queue, filling it with a few
million persistent msgs, cleanly shutting down and restarting rabbit,
and then timing how long it takes to drain the queue from a client.

Ideally, you should write your own tests which are as close a match to
the access patterns you expect to see in your applications as possible.
Only performance under those conditions is actually of any use to you.
Especially when you start using features such as publisher confirms.

Matthew