[rabbitmq-discuss] Looking for guidance on R14B04 vs. R13B03 performance
mpietrek at skytap.com
Fri Feb 17 19:17:24 GMT 2012
I'm quite sure about them all being on ramdisks. It was the first thing I
One interesting thing to note is that the 37/sec was up quite a bit from
the 25 or so that I was getting before switching to ramdisks.
Now, here's a big reveal...
The 37/sec rate were seeing is for a single client process using mirroring
with 3 queues, persistent messages, and transactions.
If I run multiple identical clients, all writing to the same queue, it
scales extremely well. With five clients, the incoming message rate is five
times as high. Pushing things up to an extreme, I capped out at about 1700
messages/sec to the same queue with 100 clients. The rate per individual
client was about half of the original 37, but that's still very reasonable
for 100 clients banging on the broker.
While I'm very happy with these results, I'm still puzzled. Given that all
clients are writing to the same queue, I'd expect resource
contention/blocking in the broker to slow things down much faster than they
do. Any comment on this? Am I overlooking anything critical to my
On Fri, Feb 17, 2012 at 4:39 AM, Simon MacMullen <simon at rabbitmq.com> wrote:
> On 15/02/12 19:18, Matt Pietrek wrote:
>> If I remove the clustering, so as to just hit a single broker, the rate
>> goes up to 900 message/sec. Thus, I'm directed back to looking for
>> latency between the master/slaves.
> I'll poke at this a bit more, but are you absolutely sure that the
> MNESIA_DIR is on a ramdisk on all the machines in the cluster? It's just
> that 36 msg/s is quite close to the performance I would expect with an
> HDD-fsync-per-commit. Just one machine could be slowing the cluster down,
> you won't see tx.commit-ok until the message is on disk on all the nodes...
> Cheers, Simon
> Simon MacMullen
> RabbitMQ, VMware
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss