[rabbitmq-discuss] Performance on ec2

[Alexis Richardson]

Srdan

I just had a quick look through your slides.  Have you tried using one
loader and one drainer and one queue, on one core, and gradually
increasing their rates?  What do you see?

alexis



On Wed, Dec 28, 2011 at 9:05 PM, Srdan Kvrgic <srdan at burtcorp.com> wrote:
>
> On Dec 28, 2011, at 19:48 , Tony Garnock-Jones wrote:
>
> On 28 December 2011 12:49, Srdan Kvrgic <srdan at burtcorp.com> wrote:
>>
>> My question is as simple as it is complex: 'Is that it?' What can I do to
>> tweak these numbers? Massively.
>
>
> Is this a transient-messaging use case (RabbitMQ as router, not relying
> particularly on disk storage), or a persistent-messaging use case (where you
> die in flames if a single message is dropped), or somewhere in-between?
>
>
> Well, it is transient in so fact that we use it to distribute messages to a
> large number of workers. In that way it is a router. But it also functions
> as a buffer. If we for instance update the workers we like to be able to
> stop and restart them without throwing messages away.
>
> Each individual message is not that important in itself. And if we loose a
> larger amount of messages, we can re-queue the affected blocks. We're big on
> idempotence and can cut ourselves some slack if we need to.
>
> That said, once you get to sending thousands of messages per second and the
> system goes all fishy on you for an indeterminate length of time, the
> re-queueing becomes… inconvenient. Inconvenient to the degree that it for
> most practical purposes stops being an option and you become prepared to
> 'invest' yourself away from those problems if at all possible.
>
>
> //S
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>