On Tue, Jun 18, 2013 at 11:04:05PM -0700, Suhrawardi wrote: > > (...) > > I don't know what exactly causes our workflow application grinding to a > halt. In my minimal ruote poc it is not happening. Thus it needs further > investigation from my part. It seems to relate to failing participants / > participants that raise an error in the concurrence block. But only when > running a lot of flows simultaneously. It does not happen when I run 5 > flows. Those errors are raised when the expected information is not found > in other systems (or these systems are simply not available). I will > investigate that further and let you know. > > > > The perfomance section doesn't tell how many ruote workers you are running > > and which storage is used for the result. > > > > The benchmarks mentioned in the README.md file are all done with a single > engine, single worker, and Redis storage. I tried FsStorage, but that was > even slower.
Hello Jarra, understood, yes, the fs storage should be slower than the Redis storage. > > > For me, there is not much difference whether I run the application with > > > multiple engines, a single engine, or handled by multiple processes. > > > > Multiple workers? > > I made an EngineDistributor (it's in lib/yaap/engine_distributor.rb) that > starts 1 or more workflow engines, each with their own database. > As there is nothing to share between different workflows, that seemed like > a good idea to speed thing up to me. But that does not make a difference. > That is wat I mean with multiple engines (and == multiple workers). I could > not see the benefits for using EngineParticipants to use multiple workers > in our case. OK, understood. > Because we use AMQP, we can easily start more then one process (bin/app.rb) > to handle the workflow requests that come in. The load will then be divided > by the different processes that are running. That's what I mean with > multiple processes. So you want to distribute the work among "engines" and not among "workers of a single engine". > > > Mind that there is a 'progress' key in the workitem hash that is dumped > > by > > > the test script. It is really weird, but some steps seem to be started > > and > > > finished more then once... While that should not be the case (workflow > > is > > > in participants/yaap_mobile_auditor/workflows/main.conf.rb). > > > > That's an interesting piece of feedback. > > > > However, I have the feeling that it is caused by the :merge_type => 'concat' I couldn't see any problems (started and finished more than once) in my test bench (see below). > (...) > > > > In your tests, the concurrent_iterator after "step5", how many branches > > does > > it "spawn"? > > > > In the example app, it does not spawn, so step 6 is never executed. In the > application we are building, it is running once in 85% of the cases, and 2 > or maybe max 3 times in the rest of the cases. In my test bench, I went for 4 branches. > In our case, we would like to start a lot of workflows at the same time > (100 / 200) and have them run all at the same time (as much as possible) > and return asap. We do a lot of IO stuff, databases / http calls etc, so > that should speed things up. > But I have a feeling that when I start 200 workflows with the example poc > application, the first step is started 200 times. When that first step is > finished for all of them, it looks like it is waiting for 10 seconds, and > only then continues with the second step. Yes, ruote 2.0 version will do that exactly, it will do the 200 first steps and then the next steps will all quick in. If there are multiple workers (and slow/human participants afterwards, that changes...) > It looks like it is doing reply and apply actions for 10 seconds, before it > starts with the second step. > The problem is still there when I remove the concurrence. It's not a problem, it's by design like that. Here is my test bench: https://github.com/jmettraux/ruote_poc Here are the stats for one set of runs: https://github.com/jmettraux/ruote_poc/blob/master/results/stats.txt At no point does the engine jam. I see no "steps start multiple times and doesn't finish" issues. For ruote 3.0, I'd love to go with a worker processing as much of a workflow as it can before handing it back. Ruote-asw works like that but it's unfinished. I don't have much time to work on open source these days... If you could pinpoint what goes wrong with your participants. I strongly think that your "multiple engines" option should perform better than "multiple workers". I don't know what your participants look like, I have the impression they are accessing the same set of resources and that may induce a synchronization cost... Hope this can help, thanks for the feedback and the nice test bench, -- John Mettraux - http://lambda.io/jmettraux -- -- you received this message because you are subscribed to the "ruote users" group. to post : send email to [email protected] to unsubscribe : send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
