Hi RabbitMQ community.  This is my first post.  I have been discussing a cluster serialization problem with OpenStack RPC&#39;s usage of RabbitMQ on the OpenStack developers mailing list with the generic subject line of &quot;RabbitMQ Scaling&quot;.<br>
<br>The relevant code versions I&#39;m using are:<br>rabbitmq-server : 2.7.1.Oubuntu4<br>python-amqplib : 1.0.0+ds-1<br>python-kombu : 1.4.3-1<br><br>I read somewhere that Kombu only uses the 0-8 level protocol, but I&#39;m not sure how to confirm that.<br>
<br>The OpenStack RPC usage pattern and the problem are shown in the following table:<br><br><span style="font-family:courier new,monospace">No cluster  Cluster of 3   AMQP Action<br>(in ms)     (in ms)<br>0.647       1.704          Type: Method (1) Channel: 1 Class: Channel (20) Method: Open (10)<br>
0.451       0.468          Type: Method (1) Channel: 1 Class: Channel (20) Method: Open-Ok (11)<br>
1.484       1.459          Type: Method (1) Channel: 1 Class: Exchange 
(40) Method: Declare (10) Exchange: XXXXXXXXXX Type: direct <br>0.431       <span style="background-color:rgb(255,255,102)"><b>2.612</b></span>          Type: Method (1) Channel: 1 Class: Exchange (40) Method: Declare-Ok (11)<br>

0.612       0.612          Type: Method (1) Channel: 1 Class: Queue (50) Method: Declare (10) Queue: XXXXXXXXXX<br>0.86        <span style="background-color:rgb(255,255,102)"><b>4.369</b></span>          Type: Method (1) Channel: 1 Class: Queue (50) Method: Declare-Ok (11) Queue: XXXXXXXXXX<br>

0.64        0.723          Type: Method (1) Channel: 1 Class: Queue (50)
 Method: Bind (20) Queue: XXXXXXXXXX Exchange: XXXXXXXXXX Routing-Key: 
XXXXXXXXXX<br>0.622       <span style="background-color:rgb(255,255,102)"><b>3.34</b></span>          Type: Method (1) Channel: 1 Class: Queue (50) Method: Bind-Ok (21)<br>
0.758       0.731          Type: Method (1) Channel: 1 Class: Exchange (40) Method: Declare (10) Exchange: nova Type: topic<br>0.193       0.194          Type: Method (1) Channel: 1 Class: Exchange (40) Method: Declare-Ok (11)<br>

0.864       0.886          Type: Method (1) Channel: 1 Class: Basic (60)
 Method: Publish (40) Exchange: nova Routing-Key: perfsvc1<br>0.029       0.034          Type: Content header (2) Channel: 1<br>0.067       0.068          Type: Method (1) Channel: 1 Class: Basic (60) Method: Consume (20) Queue: XXXXXXXXXX<br>

0.607       1.186          Type: Method (1) Channel: 1 Class: Basic (60) Method: Consume-Ok (21)<br>8.408       9.461          Type: Method (1) Channel: 1 Class: Channel (20) Method: Close (40)<br>1.8         <span style="background-color:rgb(255,255,102)"><b>10.47</b></span>          Type: Method (1) Channel: 1 Class: Channel (20) Method: Close-Ok (41)<br>
<br></span><span style="font-family:courier new,monospace">The numbers in the first and second columns are for the time between the prior action and the start of 
the action listed on that row and rows are listed in real order of occurrence.  The 
&quot;declares&quot;, bind and close are all significantly longer.  The queues and exchanges are auto delete, so the close results in the deletion of the queue and exchange.<br><br>This is from a
 wireshark trace of a single producer and a single consumer from the 
RabbbitMQ server.  <span class="il">RabbitMQ</span> is taking 
significantly longer to do something in the clustered case and it seems 
likely that &quot;the something&quot; is most likely the replication of the 
creation and destruction of the queue and exchange.<br><br>Is it known that the dynamic creation and deletion of queues and exchanges is costly in a clustered environment?  Is it known that the replication of queues and exchanges in a cluster environment is a serialization point that bottlenecks RabbitMQ scalability for this dynamic queue/exchange use pattern?<br>
<br>Ray<br><br><br><br></span>