[rabbitmq-discuss] direct queue throughput

[Charity Majors]

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.

Thanks.