[rabbitmq-discuss] performance

[Matthias Radestock]

Edwin,

Edwin Fine wrote:
> <snip>Lots of excellent suggestions of how to run tests</snip>
 > ...
> There are so many possible variations that this could become a
> full-time job!

Indeed, but, as I suggested earlier, we can start with a single test 
scenario and expand later. What's important is that the test is fully 
automated and calculates a max throughput figure that is reasonably 
accurate.

> As Martin points out, measuring throughput can be tricky. I suggest
> some sort of feedback mechanism to adjust the speed at which messages
> are sent. For example, the Erlang client could write its message
> consumption rate each second into an ets table, which the producer
> could read. As long as the rate goes up, the producer keeps pumping
> more through. As soon as the producer sees the rate plateau or even
> drop, averaged over a few measurements to prevent hysteresis, it cuts
> back.

I tried a different kind of feedback mechanism a while ago. I set up a 
test that keeps a certain number of messages "in flight" - the producer 
sends n messages and then for each message the consumer receives the 
producer sends another message. We wait a while for the system to settle 
down and then we measure the throughput. Then we pick a different 
in-flight count and repeat.

The idea behind this is that by varying the in-flight message count we 
can control how much buffering is taking place in the overall system and 
hence find the sweet spot at which it performs optimally.

Unfortunately it turns out that finding the sweet spot is hard. There 
are local maxima, and it shifts over time.


Matthias.