[rabbitmq-discuss] acquiring channels per connection

[Marek Majkowski]

On Wed, Mar 16, 2011 at 15:54, Gavin M. Roy <gmr at myyearbook.com> wrote:
> 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.

Limiting an error scope is usually a good reason for using channels.

> 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