[rabbitmq-discuss] direct queue throughput

Sat Aug 29 00:01:09 BST 2009

On Fri, Aug 28, 2009 at 05:38:58PM -0500, Chuck Remes wrote:
> > So far, so good.  But it's starting to look like this configuration
> > isn't fast enough to let me test SSDs.  Rabbitmq appears to top out at
> > a throughput rate of around 7k msgs/sec for the two queues.  Does that
> > number sound right?  The rate is the same whether I'm running on an 8
> > core box with 32 gigs of memory or a 4 core with 4 gigs.

I can crank 27kHz on my Q9450 with 4GB RAM. However, numbers like this
are utterly meaningless, without further qualification. In my case,
0-bytes message payload, and auto-ack consumer. Thus, we realy need far
more details about your setup, the nature of your exchanges, queues,
publishers and consumers before being able to suggest whether or not the
performance you're getting "sounds about right" ;)

With hardware like yours, I'd expect you to be able to push the envelope
a fair bit!

> I don't have an answer for you but I do have a few things to point out.
> 
> 1. RabbitMQ is written in Erlang. I am pretty sure the latest stable  
> releases are still a single-threaded process (though internally the  
> application uses hundreds or thousands of "green" threads). Therefore  
> you won't get much throughput increase by running on a larger multi- 
> core box.

Erlang has supported SMP for several releases, I believe first gaining
support about 4 years ago. Initially, yes, we found that very early
versions of Rabbit ran slower with the SMP support turned on that off.
However, Erlang's support for SMP has improved substantially over the
years and Rabbit benefits substantially from Erlang's SMP support.

man erl, and a quick search for SMP reveals that by default, and in
absence of any conflicting parameters, and on a supported platform, SMP
support will be enabled.

As with all non-"trivially parallisable" applications, you get
diminishing returns from going more and more parallel. That said, in
Rabbit, it's very plausible to have sockets, channels and queues running
in entirely separate processes. In short, if you structure things
correctly, you should be able to get very substantial benefits from
additional parallel hardware.

The rest of Chuck's points are absolutely valid though - we really need
a fair bit more information - which clients are you using, what is the
sustain network load, are the consumers, auto-acking, manually acking,
is qos being used?

Matthew