[rabbitmq-discuss] Looking for guidance on R14B04 vs. R13B03 performance

Wed Feb 15 10:08:53 GMT 2012

On 14/02/12 23:07, Matt Pietrek wrote:
> I'm looking to squeeze every last bit of message throughput out of our
> mirrored queue setup.

Hi Matt.

> I max out at 36 messages/sec when writing. (Yes,
> we use transactions, and we know it's not optimal, but we're valuing
> high reliability over speed. Our clients and/or servers could go away at
> any moment, so things like Publisher-acknowledge are nice, but take away
> from the fundamental disaster hardness.)
>
> Anyhow, we're running on Ubuntu 10.04 with 2.71 and the default Erlang
> install. This gives us R13B03 as the Erlang version.
>
> Question: Does anybody (and particularly the RabbitMQ folks) have any
> input on what sort of perf improvements we might get by switching to a
> newer Erlang Version?

Not much really. We haven't tested extensively but if you got 5% I think 
you would consider yourself lucky.

However, 36 msg/s is *really* slow.

Although mirrored queues are slower than normal ones I would still hope 
you could stick a couple of zeroes on the end of that figure. So I 
suspect you are not actually CPU bound at the server.

I assume when you say "using transactions" you mean publishing a single 
message per transaction? In that case you are incurring the cost of a 
network round trip and an fsync() on each publish, and I suspect that is 
what is killing your performance.

If I had to guess I would suspect the fsync is the worst of the problem. 
Assuming the 36 msg/s is from some test app, you might want to remove 
the tx.select and replace the tx.commit with some meaningless 
synchronous request (basic.qos is a favourite) and see what happens to 
your message rate. If it shoots up, the fsync is the problem. If it 
doesn't, the network round trip is.

When you have the answer to that, you know whether you're going to want 
to spend money on fancy networking hardware or SSDs...

Of course, *really* I would suggest you need to be publishing more 
messages per round-trip / fsync. So either batch multiple publishes into 
a transaction or start using confirms instead. I know you say that they 
"take away from the fundamental disaster hardness" but I'm not sure I 
understand what you mean by that. Both confirms and tx give you a way to 
know when a given message is definitely on disc. And in fact tx is 
implemented in terms of confirms these days.

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware