Should I stay or Should I Go

[peterpunk]

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.

We want to do stress test before launching an app that will use Ruote as orchestrator.

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

Any suggestion/tip for the stress test?
Any suggestion/tip for making rabbitmq/eventmachine working smoothly with the receive (we did not have problems there, but tips are welcome)?
In which case the performance can go down?
What's a reasonable number of processes 100/1000/10000?

Sorry for all the questions.

And thank you again for the nice work and the support!

P

[John Mettraux]

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.

Hello Pedro,

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

I'd say, don't use ruote for a new application. Please read:
https://groups.google.com/forum/#!topic/openwferu-users/g0jZuWeoXOA

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

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

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


Cheers,

--
John Mettraux - http://lambda.io/jmettraux

[Pedro Visintin]

On Tue, Dec 17, 2013 at 7:12 PM, John Mettraux <jmet...@gmail.com> wrote:

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.

Hello Pedro,

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.

Sorry about the description of the issue, but maybe there's a known issue in some condition that I can look at it ;-)

I will provide more information ;-)

 

> We want to do stress test before launching an app that will use Ruote as
> orchestrator.

I'd say, don't use ruote for a new application. Please read:
https://groups.google.com/forum/#!topic/openwferu-users/g0jZuWeoXOA

We have our app already integrated with Route :-( and we like it so far, except some issues.

 

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

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

Thx ;-)

 

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

Good tip.

 

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

> Sorry for all the questions.
>
> And thank you again for the nice work and the support!

Thanks again :-)

 

I hope the people using ruote + RabbitMQ will chime in.


Cheers,

--
John Mettraux   -   http://lambda.io/jmettraux

--
--
you received this message because you are subscribed to the "ruote users" group.
to post : send email to openwfe...@googlegroups.com
to unsubscribe : send email to openwferu-use...@googlegroups.com
more options : http://groups.google.com/group/openwferu-users?hl=en
---
You received this message because you are subscribed to the Google Groups "ruote" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openwferu-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Pedro   Visintin . S o f t w a r e   A r c h i t e c t
http://www.pedrovisintin.com

"Lo que hagas, hacelo con pasión"

[Kiran Patil]

How about trying https://github.com/geekq/workflow ?

Thanks,
Kiran.

[John Mettraux]

On Mon, Dec 23, 2013 at 02:53:23AM -0800, Kiran Patil wrote:
>
> How about trying https://github.com/geekq/workflow ?

https://groups.google.com/forum/#!topic/openwferu-users/xQMvOrbP1yo

John