Open Stack

On Wed, Jan 30, 2013 at 9:48 AM, Eric Windisch <eric at cloudscaling.com>wrote:

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

   - All machines are 2 CPU VMs
   - Three VMs:
      - RPC load driver (caller)
      - OpenStack simulated service (callee)
      - 3 cluster RabbitMQ with mirroring enabled.
   - 10 concurrent load generating threads achieving close to maximum
   throughput
   - The amqp_rpc_single_reply_queue enabled (fast RPCs)
   - RPC calls (not casts)

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.

Here are the results:

RPC envelope disabled:  170 RPCs/second
RPC envelope enabled:  190 RPCs/second
The performance cost of enabling RPC envelopes is about a 10% reduction RPC
throughput.

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.

I'm not really suggesting a change, more just mentioning as an FYI.

Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130220/682f7533/attachment.html>