[rabbitmq-discuss] Performance on ec2

[Srdan Kvrgic]

Nope, can't say that I have. 

It's not really the use case though - in real life the queues are actually significant.

I'll try it though. If that'll yield some insight. Hell, I'd try eating a balanced diet and getting plenty of sleep if that could help.

//S


On Dec 29, 2011, at 17:53 , Alexis Richardson wrote:

> 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
>>