<div class="gmail_quote">On Wed, Jan 30, 2013 at 9:48 AM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div>Furthermore, the code currently double-serializes all the content. Kombu serializes data with JSON transparently, unless told otherwise, and the same is done with ZeroMQ. At least with ZeroMQ, if the array is convertable via bytes(), then we can send it without the double serialization, but the envelope is currently a dict, so the double-serialization is still required... I'm not so certain if we can avoid it for Kombu, but I do know the default JSON serialization can be disabled.</div>
</span></blockquote></blockquote></div>I was curious what the cost of this double serialization would be for the AMQP based Kombu RPC implementation (RabbitMQ).  I took an RPC throughput measurement with this set up:<br><ul>
<li>All machines are 2 CPU VMs<br></li><li>Three VMs:</li><ul><li>RPC load driver (caller)</li><li>OpenStack simulated service (callee)</li><li>3 cluster RabbitMQ with mirroring enabled.</li></ul><li>10 concurrent load generating threads achieving close to maximum throughput</li>
<li>The amqp_rpc_single_reply_queue enabled (fast RPCs)</li><li>RPC calls (not casts)<br></li></ul><p>In a prior study I used 9 load driver / simulated service pairs to drive higher throughput, but this single pair is good enough to get a rough idea.</p>
<p>Here are the results:</p><p>RPC envelope disabled:  170 RPCs/second<br>RPC envelope enabled:  190 RPCs/second<br></p>The performance cost of enabling RPC envelopes is about a 10% reduction RPC throughput.<br><br>The double serialization that Eric mentions is the reason for the slow down.  I think the only reason the double serialization was added was in preparation for signature signing.  If Grizzly goes out this way, then we will just have to take the 10% hit to AMQP RPC in Havana, when the envelope will be enabled with no option to disable it.  An alternative is to remove the JSON serialization from the current envelope code, but it might be too late for Grizzly.<br>
<br>I'm not really suggesting a change, more just mentioning as an FYI.<br><br>Ray<br>