Hi RabbitMQ community.� This is my first post.� I have been discussing a cluster serialization problem with OpenStack RPC's usage of RabbitMQ on the OpenStack developers mailing list with the generic subject line of "RabbitMQ Scaling".<br>
<br>The relevant code versions I'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'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
"declares", 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 "the something" 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>