[rabbitmq-discuss] direct queue throughput

Mon Aug 31 20:37:42 BST 2009

Hi Charity,

On Mon, Aug 31, 2009 at 12:25:07PM -0700, Charity Majors wrote:
> > 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.

Ahh right, yes. If noAck is true, then you're ok.

AMQP says that a broker shouldn't forget about a msg until it's been
ack'd. Now this can either happen by an explicit ack coming from the
consumer, or from an implicit ack, by setting noAck to true when
subscribing to the queue. Yes, the unfortunate naming of "noAck" is, um,
unfortunate. Internally, we tend to invert this and then call it
AckRequired.

> > 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.

Do let us know how you get on.

Cheers,

Matthew