[rabbitmq-discuss] another performance question

[Matthias Radestock]

Mark,

On 15/07/13 17:45, mark.geib at echostar.com wrote:
> Recently we started a new project using rabbitmq to handle large amounts
> of data, over 40kHz message rate and message sizes of a few kilobytes.
> The project depends on using a topic exchange with routing keys of the
> form AA.BB.CC.DD.EE. Consumers are able to bind a queue with a given
> wildcard pattern in order to receive a subset of the message stream
> published by one publisher. There is always one consumer that binds with
> the "#" routing key to receive all messages.
>
> We have started testing against a broker running on a machine with 8
> cores, about 2GHz each, with 32GB ram, and over a terabyte of free disk
> space. I am publishing with a single erlang client to a topic exchange.
> I am only able to publish at about 15kHz before I see flow control kick
> in on the management UI for the connection. This is with no queue bound
> to the exchange, so rabbitmq only needs to receive the messages and drop
> them. So at 15kHz I see flow control kicking in, but the machine is not
> busy, all 8 cores show 85-95% idle. It looks like the server is
> basically idle.

With a single publisher, and no bound queues, there is very limited 
scope for any parallelism, so it is not surprising to see low CPU 
utilisation. Having said that, the scenario you outline should keep 
about 2 cores busy, so on an 8-core machine you should only see 75% idle 
overall. And the rate you are seeing is very low too.

Please run the MulticastMain example that ships with the Java client, to 
get a baseline performance figure for comparison. When I run that on my 
machine, which has a spec quite similar to the one you describe, I see 
the following:

$ sh runjava.sh com.rabbitmq.examples.MulticastMain -y 0 -t topic -s 10000
starting producer #0
time: 1.000s, sent: 23808 msg/s
time: 2.000s, sent: 51565 msg/s
time: 3.000s, sent: 55242 msg/s
time: 4.000s, sent: 53159 msg/s
time: 5.000s, sent: 48668 msg/s
time: 6.000s, sent: 50210 msg/s
time: 7.000s, sent: 54886 msg/s
time: 8.001s, sent: 54003 msg/s
time: 9.001s, sent: 52832 msg/s
time: 10.001s, sent: 51103 msg/s
time: 11.001s, sent: 54270 msg/s
time: 12.001s, sent: 50181 msg/s
time: 13.001s, sent: 53384 msg/s
time: 14.001s, sent: 52203 msg/s
time: 15.001s, sent: 54684 msg/s
time: 16.001s, sent: 50603 msg/s

So that's ~50kHz for 10,000 byte messages published to a topic exchange 
with no bound queues. With hipe compilation enabled that increases to 
~70kHz. Obviously the above was run over localhost rather than the 
network, but that should have no bearing on throughput.

There was one performance-related bug in the Erlang client which got 
fixed in 3.1.2: "25521 fix negotiated frame-max handling, which was 
being ignored (since 2.0.0)". However, that shouldn't have much of an 
effect for small(ish) messages, so I doubt that's your problem.


Regards,

Matthias.