[rabbitmq-discuss] [PATCH] Suggestions for improving the RabbitMQ Erlang Client

Tue Oct 8 15:03:13 BST 2013

First of all, thanks again for this. We were aware that the Erlang 
client needed some performance improvements; you've provided some very 
useful analysis and patches.

I've been through the various changes you propose, and have some comments:

On 03/09/13 13:35, Jesper Louis Andersen wrote:
> The optimization is straight forward: Read as much data as possible from
> the underlying socket per call.

I think this is fairly uncontroversial, and I can certainly see large 
gains there. Should find its way into 3.2.0.

> Let us look at what the `rabbit_writer` is doing.

<snip>

> Ouch! All writes are synchronous!

<snip>

> RabbitMQ itself does not use the sync writes for anything but closing
> down the line. So we can probably safely change to use async writes on
> the socket.

You are correct that the synchronous writing hurts performance - but 
it's not quite enough to just switch to async calls. The test suite 
starts failing, for a start :-)

So there is a bit of work needed here to ensure that the messages to the 
writer get flushed before the socket gets closed. I've started work on 
this, and it should end up in 3.2.0.

<snip re channels manager>

> I would probably have chosen a design based on an ETS lookup table. And
> then have kept the state in the channel process itself to maximize
> parallel behaviour. In turn, we can avoid spending a lot of time
> updating internal memory state in a process on the critical path which
> would speed up the system by quite a lot. Also, we are paying reductions
> on busy channels. This will help fairness.
>
> Also, this means we can do away with the channels_manager process
> entirely. There is no need since a decoded message can just be forwarded
> to the channel directly, skipping an unneeded message pass on the
> critical decoder path.

This is reasonable - but of course it's a more substantial change, 
unlikely to happen particularly soon.

> The writer process inside RabbitMQ is something I wanted to optimize as
> well, so I tried changing two things in it. First, I avoided a
> recomputation of `iolist_size/1` on every received message. And I just
> dropped keeping a small 1414 byte packet size around. The rationale is
> this: either we will be running at a high pace in the writer code and
> then easily exceed the 1414 byte packet size. In this case, bumping it
> to 64 kilobytes and making few calls to the underlying port seems to be
> the right thing to do.

Hmm. I wasn't actually able to measure a discernable performance 
difference with these changes to the writer. Were you?

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, Pivotal