<div class="gmail_quote">On Tue, Nov 13, 2012 at 1:06 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></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 11/13/2012 01:24 PM, Vishvananda Ishaya wrote:<br>
><br>
> On Nov 13, 2012, at 10:14 AM, Ray Pekowski <<a href="mailto:pekowski@gmail.com">pekowski@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:pekowski@gmail.com">pekowski@gmail.com</a>>> wrote:<br>
>><br>
>> My question is whether anyone thinks it is a worthwhile effort to<br>
>> investigate code changes to the Openstack RPC that would make the RPC<br>
>> responses flow on static exchanges and queues?<br>
>><br>
><br>
> Yes I think this is worthwhile. A few people have tried this out and<br>
> there doesn't seem to be any reason why this wouldn't work. This should<br>
> be done in oslo-incubator (formerly openstack-common)<br>
<br>
</div>The dynamic creation is of *queues*, right?  Not of exchanges and queues<br>
as specified before?  It only seems valuable to have dynamic queues for<br>
responses, which I'm pretty sure is how it works.<br></blockquote><div><br>I don't know for sure if exchanges are being created or not, but here is the output from a kombu log an RPC and you will see an exchange_declare on the cleint and server side for e8e85bf237944223994eecd283a582da.<br>
<br>[Kombu channel:1] message_to_python(<amqplib.client_0_8.basic_message.Message object at 0x4be99d0>)<br>[Kombu connection:0x4a37d50] establishing connection...<br>[Kombu connection:0x4a37d50] connection established: <kombu.transport.pyamqplib.Connection object at 0x4be1c10><br>
[Kombu connection:0x4a37d50] create channel<br>[Kombu channel:1] exchange_declare(nowait=False, exchange=u'e8e85bf237944223994eecd283a582da', durable=False, arguments=None, type='direct', auto_delete=True)<br>
[Kombu channel:1] prepare_message('{"failure": null, "result": ["000000", "000001", "000002", "000003", "000004", "000005", "000006", "000007", "000008", "000009", "000010", "000011", "000012", "000013", "000014", "000015", "000016", "000017", "000018", "000019"]}', priority=0, headers={}, properties={'delivery_mode': 2}, content_type='application/json', content_encoding='utf-8')<br>
[Kombu channel:1] basic_publish(<amqplib.client_0_8.basic_message.Message object at 0x4cb1550>, mandatory=False, routing_key=u'e8e85bf237944223994eecd283a582da', immediate=False, exchange=u'e8e85bf237944223994eecd283a582da')<br>
[Kombu channel:1] close()<br>[Kombu connection:0x4a37d50] create channel<br>[Kombu channel:1] exchange_declare(nowait=False, exchange=u'e8e85bf237944223994eecd283a582da', durable=False, arguments=None, type='direct', auto_delete=True)<br>
[Kombu channel:1] prepare_message('{"failure": null, "result": null, "ending": true}', priority=0, headers={}, properties={'delivery_mode': 2}, content_type='application/json', content_encoding='utf-8')<br>
[Kombu channel:1] basic_publish(<amqplib.client_0_8.basic_message.Message object at 0x4cb1e90>, mandatory=False, routing_key=u'e8e85bf237944223994eecd283a582da', immediate=False, exchange=u'e8e85bf237944223994eecd283a582da')<br>
[Kombu channel:1] close()<br>[Kombu connection:0x4a37d50] create channel<br><br><br>[Kombu channel:1] message_to_python(<amqplib.client_0_8.basic_message.Message object at 0x4be99d0>)<br>[Kombu connection:0x4a37d50] establishing connection...<br>
[Kombu connection:0x4a37d50] connection established: <kombu.transport.pyamqplib.Connection object at 0x4be1c10><br>[Kombu connection:0x4a37d50] create channel<br>[Kombu channel:1] exchange_declare(nowait=False, exchange=u'e8e85bf237944223994eecd283a582da', durable=False, arguments=None, type='direct', auto_delete=True)<br>
[Kombu channel:1] prepare_message('{"failure": null, "result": ["000000", "000001", "000002", "000003", "000004", "000005", "000006", "000007", "000008", "000009", "000010", "000011", "000012", "000013", "000014", "000015", "000016", "000017", "000018", "000019"]}', priority=0, headers={}, properties={'delivery_mode': 2}, content_type='application/json', content_encoding='utf-8')<br>
[Kombu channel:1] basic_publish(<amqplib.client_0_8.basic_message.Message object at 0x4cb1550>, mandatory=False, routing_key=u'e8e85bf237944223994eecd283a582da', immediate=False, exchange=u'e8e85bf237944223994eecd283a582da')<br>
[Kombu channel:1] close()<br>[Kombu connection:0x4a37d50] create channel<br>[Kombu channel:1] exchange_declare(nowait=False, exchange=u'e8e85bf237944223994eecd283a582da', durable=False, arguments=None, type='direct', auto_delete=True)<br>
[Kombu channel:1] prepare_message('{"failure": null, "result": null, "ending": true}', priority=0, headers={}, properties={'delivery_mode': 2}, content_type='application/json', content_encoding='utf-8')<br>
[Kombu channel:1] basic_publish(<amqplib.client_0_8.basic_message.Message object at 0x4cb1e90>, mandatory=False, routing_key=u'e8e85bf237944223994eecd283a582da', immediate=False, exchange=u'e8e85bf237944223994eecd283a582da')<br>
[Kombu channel:1] close()<br>[Kombu connection:0x4a37d50] create channel<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The use of temporary queues for responses is discussed in the AMQP spec<br>
(is at least in the 0-9-1 version I just pulled up), so what we're doing<br>
seems to be recommended in general.<br></blockquote><div><br>From the above log data you see amqplib.client_0_8.basic.  I think I read somewhere that kombu dumbs the protocol down to 0.8.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
My concern with using static reply queues is the uncertainty that comes<br>
along with that.  When you create a temporary queue *only* for the<br>
purpose of receiving a response, you know that the only thing you're<br>
going to get is the response.  When you start leaving queues around and<br>
reusing them, it's not guaranteed anymore.  That would be my biggest<br>
concern.<br>
<br>
It may be doable in a way that's safe enough.  We just need to be *very*<br>
careful.<br>
<br>
I'm also curious about the volume of rpc calls you were doing in your<br>
testing, and how that may relate to the size of a deployment (or the<br>
size of a single cell in the upcoming cells feature).<br></blockquote><div><br>My volume of RPC calls is artificial.  It is a test program that just does RPCs as fast as it can.  The performance was strikingly bad for clustered RabbitMQ.<br>
<ul><li>A single 8 processor RabbitMQ with no clustering achieved 410 RPC calls/sec at 580% CPU utilization<br></li><li>A cluster of two RabbitMQs servers achieved 68 RPC calls/sec at 140% CPU utilization on each</li><li>
A cluster of three RabbitMQ servers schieved 55 RPC calls/sec at 80% CPU utilization on each<br></li></ul>This is with 5 multiple simulated services an 10 load generating callers per service all driving the highest rate they could.  Note that both of the cluster cases had already maxes out at 2 services (20 load generating clients).<br>
<br>It is not realistic, but it does show an upper bound.  The hard part would be figuring what level of RPC throughput would be expected from some number of compute nodes, tenants, VMs, projects or some other unit of size.  Do you have any insights into the answer to that question?<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></span></blockquote><div><br>Thanks,<br>Ray <br></div>
</div><br>