[rabbitmq-discuss] direct queue throughput

Charity Majors charity at lindenlab.com
Mon Aug 31 20:25:07 BST 2009

On Sat, Aug 29, 2009 at 3:44 AM, Matthew Sackman<matthew at lshift.net> wrote:
> Hi Charity,
> On Fri, Aug 28, 2009 at 04:51:19PM -0700, Charity Majors wrote:
>> We aren't acking at all.
> Err, this seems odd. Do you mean that your consumers set noAck to true
> when setting up the subscription to the queue? If you're not, and you're
> not explicitly acking then Rabbit will be keeping a copy of the message
> in memory all the time, because it won't discard messages until it
> receives an ack from the consumer for the msg.

I'm a little confused about this sentence here, but no, I'm not
explicitly acking anything.  I have no_ack set to True, and no durable
queues or persistent delivery mode, so I shouldn't be storing anything
in memory or disk.  It doesn't appear as though I am.

> Yes, I think this backs up my theory - if a null consumer isn't going
> any faster, then I would definitely point the finger at the producers.
> How big are the messages you're sending? If you're all on the same box,
> I find this a bit surprising - I can push above 400M*Bytes*/s over
> localhost loopback to and from Rabbit.

Yeah, this makes sense.  Let me try taking RMQ out of the equation
completely and seeing how fast the producers are producing messages.


More information about the rabbitmq-discuss mailing list