[rabbitmq-discuss] Connection and Channel Management
glen.wagley at gmail.com
Fri Mar 9 16:02:52 GMT 2012
Thanks for the input. This is exactly the type of info I'm looking for!
On Fri, Mar 9, 2012 at 4:48 AM, Marek Majkowski <majek04 at gmail.com> wrote:
> On Thu, Mar 8, 2012 at 23:51, Glen Wagley <glen.wagley at gmail.com> wrote:
> > I'm experimenting with rabbitmq to replace our current message queuing
> > implementation. Currently our test system is comprised of a REST web
> > service, a 3-node rabbitmq cluster, and a windows service. The REST
> > acts as a front-end for our clients to send data to which then gets
> > published from the REST service to our rabbitmq cluster. The windows
> > has multiple subscriber threads that consume the messages from the
> > and do things like insert data from the message into a relational
> > send an email containing the message contents, etc.
> > Right now I am trying to figure out if I am limiting throughput to the
> > cluster because each instance of the REST service and each instance of
> > windows service only has one connection to the cluster BUT multiple
> > channels. We support about two dozen message types right now and I've
> > created a channel for each one. Some channels have a lot of messages
> > through while some have little to none depending on the day. Is there a
> > recommended approach to number of connections vs channels? We are
> > to load test the system and I am trying to understand what could be
> > to improve performance/throughput. Thanks.
> There aren't any specific guidelines about connections vs channels.
> Depending on the application, it may be more convenient to use
> multiple connections or channels. Use what is more convenient.
> Of course, if possible you should reduce number of
> connections - connections consume constrained resources
> (file descriptors).
> Having said that there is one particular case when you could
> benefit from having multiple connections.
> In a situation when RabbitMQ runs of memory (high memory
> watermark), it will stop accepting new messages. But due to the
> limitations of AMQP protocol, it can't be done on per-channel
> basis - a full connection will be stopped in such case.
> To rephrase - when rabbit runs out of memory the connections
> on which messages are being published will be temporarily
> throttled. You won't be able to do anything on that connection
> until rabbit recovers - that includes consuming messages.
> So, if you wish to be shielded against this situation, you
> may want to keep publishers on a separate connection
> than consumers. That will ensure that even in the
> out-of-memory case the consumers will be able to do their
> job (and thus help rabbitmq free memory faster)
> Hope that helps,
Glen Wagley <glen.wagley at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss