matthias at lshift.net
Tue Sep 2 05:08:44 BST 2008
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
> 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
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.
More information about the rabbitmq-discuss