[rabbitmq-discuss] Connection and Channel Management

884 views
Skip to first unread message

Glen Wagley

unread,
Mar 8, 2012, 6:51:36 PM3/8/12
to rabbitmq...@lists.rabbitmq.com
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 service 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 service has multiple subscriber threads that consume the messages from the cluster and do things like insert data from the message into a relational database, 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 the 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 flowing through while some have little to none depending on the day. Is there a recommended approach to number of connections vs channels? We are starting to load test the system and I am trying to understand what could be tweaked to improve performance/throughput. Thanks.

--
Glen Wagley <glen....@gmail.com>

Marek Majkowski

unread,
Mar 9, 2012, 6:48:59 AM3/9/12
to Glen Wagley, rabbitmq...@lists.rabbitmq.com

Glen,

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,
Marek
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq...@lists.rabbitmq.com
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Simon MacMullen

unread,
Mar 9, 2012, 6:57:58 AM3/9/12
to Glen Wagley, rabbitmq...@lists.rabbitmq.com
On 08/03/12 23:51, Glen Wagley wrote:
> 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
> the 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
> flowing through while some have little to none depending on the day. Is
> there a recommended approach to number of connections vs channels? We
> are starting to load test the system and I am trying to understand what
> could be tweaked to improve performance/throughput. Thanks.

To some extent the answer is "do your own tests", but to get you
thinking in the right direction, here are some pertinent facts:

* Starting a new channel on an existing connection involves one network
round trip - starting a new connection takes several.

* Each connection uses a file descriptor on the server. Channels don't.

* Publishing a large message on one channel will block a connection
while it goes out. Other than that, the multiplexing is fairly transparent.

* Connections which are publishing can get blocked if the server is
overloaded - it's a good idea to separate publishing and consuming
connections.

* There is only one AMQP parser process per connection. Therefore if you
have less connections than CPU cores, and are CPU bound in AMQP parsing,
you might not make full use of your server. This is generally pretty
rare but sounds like it may apply to you.

Cheers, Simon

--
Simon MacMullen
RabbitMQ, VMware

Glen Wagley

unread,
Mar 9, 2012, 11:02:52 AM3/9/12
to Marek Majkowski, rabbitmq...@lists.rabbitmq.com
Thanks for the input. This is exactly the type of info I'm looking for!
--
Glen Wagley <glen....@gmail.com>

Glen Wagley

unread,
Mar 9, 2012, 11:13:06 AM3/9/12
to Simon MacMullen, rabbitmq...@lists.rabbitmq.com
Simon,
Thanks for the information. I expected that a lot of this would depend on my particular implementation and that some of these things would become apparent as we apply load to the system. The facts you have provided me are excellent and will help shape the system moving forward. Thanks! Off to do more testing...
--
Glen Wagley <glen....@gmail.com>
Reply all
Reply to author
Forward
0 new messages