<div dir="ltr">We are looking at the best way to use only one connection and have only the channel created each time. �Bear in mind that its all happening on the same physical server and the servers that I refer to are actually software services as opposed to different physical machines. �So network latency shouldnt be a big problem here.<div>
<br></div><div>It is possible I need to rethink my strategy a little.</div><div><br></div><div>The application is for trading.</div><div><br></div><div>S1 receives a signal to open a trade and sends the order to S2 which is responsible for sending the trade to the brokers. �When S1 receives a signal to open the trade it creates an object to manage all the communication back and forth between the broker. �So it creates a queue that will route all incoming messages to do with that specific trade back to the object. �For this reason the object (which is a new object for each trade) will create a new channel, queue and binding, specifically for the life of the trade.</div>
<div><br></div><div>Thanks for the suggestions, I may need to think about this process and decide which is the best way to use RMQ.<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Feb 13, 2013 at 5:51 PM, Simon MacMullen <span dir="ltr">&lt;<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 13/02/13 13:18, Rob Woolfson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What is the suggested best practice for speeding up my process?<br>
</blockquote>
<br></div>
There are several things you can do:<br>
<br>
Creating a new connection / channel takes several network round trips - can you get P1 to keep a connection / channel open?<br>
<br>
Creating a new queue is quite expensive (especially if it&#39;s durable) - can C1 reuse its reply queue?<br>
<br>
Declaring / binding the queue and exchange, and consuming from the queue also takes some network round trips by default, since each AMQP method will cause a corresponding -ok method to be sent back. To eliminate the round trips you can use the nowait parameter to declare / bind / consume - this prevents an -ok method from coming back, so all the requests can be pipelined. Alternatively if your reply queue is reused you can skip redeclaring it each time, just declare it and consume from it once.<br>

<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>Rob Woolfson - CTO<br>mobile:+972-544904157<br>office:+972-3-5353751
</div>