<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>