On Tue, Dec 17, 2013 at 01:38:28PM -0800, peterpunk wrote:
> Hi everybody:
> We have been using Ruote for 2 and a half years now, we are happy with it
> and we appreciate all your work done there.
> We have to decide to continue using or replace it with something else, but
> there's no other workflow like route so far.
> The things that will force us to migrate is that sometimes is not stable
> and some process got stacked and them have to be killed by console, and we
> could not identify when that exactly happens, maybe you know about it or
> how can we detect the problem easily.
Sorry, many things can go wrong. I did not know about it, it's the first time
you write about that. I think you can detect the problem easily: "process
stuck". Please note that your description of the issue is very very vague and
the details you give below further extend the set of things that may^H^H^H
will go wrong.
> We want to do stress test before launching an app that will use Ruote as
I'd say, don't use ruote for a new application. Please read:
> Our architecture is a distributed app with several backends orchestrated by
> Ruote and using messaging with rabbit-mq, the only way to talk with Ruote
> is with rabbit-mq.
> We have 3 queues, 1 for launching processes, 1 for workitems, and 1 for
> Any suggestion/tip for the stress test?
Your existing system is already teaching you a lot about an ideal/desired
performance. "From point A to point B, it takes 10s". "When there is a lot of
work, it takes 25s", "when the process X is stuck, it takes ..."
You need to have those measurements in your stress system too.
> Any suggestion/tip for making rabbitmq/eventmachine working smoothly with
> the receive (we did not have problems there, but tips are welcome)?
Isolate the "receive" (no ruote involved) and measure it.
Measure it preventively.
When something goes wrong, compare bad time metrics to fair weather metrics.
> In which case the performance can go down?
Many possibilities for ruote, but for rabbit-mq, I cannot say.
> What's a reasonable number of processes 100/1000/10000?
If they are all idle, 100k is reasonable too. (well, depends on the backend).
Once you have a stress test system, you can measure for 100/1000/10000 at
> Sorry for all the questions.
> And thank you again for the nice work and the support!
I hope the people using ruote + RabbitMQ will chime in.
John Mettraux - http://lambda.io/jmettraux