[rabbitmq-discuss] acquiring channels per connection

[Gavin M. Roy]

On Wednesday, March 16, 2011 at 11:42 AM, Marek Majkowski wrote: 
> On Tue, Mar 15, 2011 at 07:11, vorad <vorad.1100 at gmail.com> wrote:
> > How expensive would be to do
> > this (one channel per request) from the rabbitmq perspective and also from
> > the Pika's perspective ?
> 
> Well, not that expensive if your RabbitMQ is close to the web server.
> Opening channel is a synchronous action - a full roundtrip is required.
> 
> To avoid that roundtrip you may hava a pool and reuse open channels.
In addition, you're not buying anything by using more connections as they'll still use the same single process IOLoop.

For what it's worth, I use Pika and Tornado with one connection and channel per Tornado backend and hold on to the for the life of the backend, across multiple RequestHandler invocations.

If you want to use multiple channels, I recommend having a sound reason for it. At the protocol level, it's nothing more than a numeric identifier for the frame routing. At the python level it's a set of two class instances which need to reside in memory. I can't think of a reason in my web applications that I would use more than one channel.

For example, if you want to listen on multiple queues, just have multiple callbacks for channel.basic_consume.

I guess my main point is using more channels and more connections doesn't offer any real value and adds additional overhead since you're bound to the same single process for responding to events.

I would imagine if you could saturate a socket without saturating CPU that there could be some value, but offhand I can't imagine that is possible, as the OS's use of CPU would be saturated.

Gavin 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110316/07305b46/attachment-0001.htm>