Ok, my main concern about having one channel per application/tornado instance is that I wouldn't know what's the request that corresponds to a particular error when I catch it. That's the way I do it now (one channel per application) and I still haven't figured things out on the error side.<div>
<br></div><div>Other than this it feels like adding another pool of objects to manage it's not such a good idea so if I can stick with one connection and one channel it would be great.</div><div><br></div><div>Thanks for your feedback.<br>
<br><div class="gmail_quote">On Wed, Mar 16, 2011 at 5:54 PM, Gavin M. Roy <span dir="ltr"><<a href="mailto:gmr@myyearbook.com">gmr@myyearbook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<div><div class="im">
<span>
<br>
</span>
<span></span>
<p style="color:#a0a0a0">On Wednesday, March 16, 2011 at 11:42 AM, Marek Majkowski wrote:</p>
</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div class="im">On Tue, Mar 15, 2011 at 07:11, vorad <<a href="mailto:vorad.1100@gmail.com" target="_blank">vorad.1100@gmail.com</a>> wrote:<br></div><div class="im"><blockquote type="cite">
<div> How expensive would be to do<br>this (one channel per request) from the rabbitmq perspective and also from<br>the Pika's perspective ?<br></div></blockquote><br>Well, not that expensive if your RabbitMQ is close to the web server.<br>
Opening channel is a synchronous action - a full roundtrip is required.<br><br>To avoid that roundtrip you may hava a pool and reuse open channels.</div></div></div></span></blockquote><div>In addition, you're not buying anything by using more connections as they'll still use the same single process IOLoop.</div>
<div><br></div><div>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.</div><div>
<br></div><div>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.</div>
<div><br></div><div>For example, if you want to listen on multiple queues, just have multiple callbacks for channel.basic_consume.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><font color="#888888"><div>Gavin</div>
</font></div>
</div></blockquote></div><br></div>