<div class="gmail_quote">On Sat, Jan 19, 2013 at 11:47 PM, Ray Pekowski <span dir="ltr"><<a href="mailto:pekowski@gmail.com" target="_blank">pekowski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some possible things that could make the results lower than you would<br>
expect are:<br>
1) All machines are virtual machines, including the RabbitMQ servers.<br>
Virtualization typically costs around 40%.<br>
2) All VMs were only assigned 2 CPUs. The CPUs are Intel Xeon E5620 @ 2.4 GHz.<br>
<span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div>I forgot to mention some other possible reasons:<br><br>3) OpenStack RPC implementation over AMQP (RabbitMQ and Qpid) sends two messages for each reply. This means there are three messages sent per RPC, one for the request and two for the reply.<br>
<br>The effective rate in terms of RabbitMQ message/sec for the cluster of
three RabbitMQ servers and mirroring enabled and the OpenStack patch to
use a single queue per process for the reply is 812 X 3 ~= 2400 msg/sec,
which might still be considered low but perhaps the 2 CPU VMs per
RabbitMQ server is the biggest reason for this.<br><br>4) The OpenStack RPC producers re-declare the queues and exchanges upon which they send messages. I say re-declare, because under normal circumstances in the OpenStack implementation, the consumers exist before the producers and so have already declared/created the exchanges and queues. I think this is done in case an RPC call is made to a service that isn't up at the time. I wonder that is a good practice, but I may be missing some other reason for it. I might play around with prototyping a removal of the producer side re-declares.<br>
<br>Ray<br>