[rabbitmq-discuss] RabbitMQ experience
sustrik at imatix.com
Wed Jan 28 06:53:53 GMT 2009
Tony Garnock-Jones wrote:
> Martin Sustrik wrote:
>> Hm, interesting. I've never thought of that kind of metric. Possibly
>> something like "if there's a peak lasting N seconds containing M
>> messages there's a 50% chance that the max latency will exceed X
>> microseconds". The obvious problem is that there are to many free
>> variables in the formula.
> Yeah. Hmm. Well, LD50 is measured IIRC along the lines of "LD50 is this
> many mg/kg in mice", so there's a dependency on species, amount of
> bodyweight, and amount of drug. Still doesn't help with our problem, of
> course :-)
What can be done for example is to simulate some particularly terrible
real-world market data peak and show that the solution is capable of
handling it with latencies below N in 99.99% of cases.
Still, while vendors love percentile statistics, customers want hard
limits forgetting that they won't run the system on hard realtime OS
anyway... something more "straightforward" would do a better marketing job.
> Those charts you linked earlier were interesting. The 1/lambda chart had
> a sharp corner where the network took over from the CPU as the
> bottleneck. Perhaps the location (and sharpness?) of the corner is a
> relevant measure?
That metric may be pretty interesting to understand how the system
behaves, but you can easily make it look better by slowing down
processing of the message content (linearly bound part of the algorithm)
instead of speeding up processing of the message as a unit (constantly
bound part of the algorithm).
You can make it unambiguous by mentioning 2 values: "for message sizes
below 32 bytes the system hits its processing limit at 250 nanoseconds
per message i.e. 4 million messages a second."
More information about the rabbitmq-discuss