HI John,

>> 
>> is there a way to 'reserve' workers for specific participants.
> 
> Hello,
> 
> basically, there are two ways.
> 
> a) use Participant#on_accept?
> http://ruote.rubyforge.org/implementing_participants.html#accept
> 

hm, I guess this would not work, because we need to reserve workers for 
participant, not participants for workitems (?)

> b) subclass the Worker to make it discard certain msgs based on the
> participant name
> 
> 

thanks for this tip,
looks as a working solution, I will give it a try.
maybe this is something for a future ruote update?


>> We have the requirement that some workitems need to be processed quite 
>> instantly (1-2 seconds).
>> But under medium workload the engine reacts really slow and needs minutes to 
>> process new workitems, even with a lot of worker-processes (currently 5).
> 
> What is medium workload for you guys?

about 20-50 workitems per minute ..

> What storage implementation do you use?
currently we use the Redis storage, btw. ruote-mon works so far for us, but its 
a bit slower then redis, so currently ruote-redis

> What version of ruote?
2.3.0

> What version of Ruby?
1.9.3

> Is the datastore on the same host as the workers?
yes, all on one machine .. 

> Are the workers disseminated on multiple hosts?
no 
> What kind of deployment? EC2? Own servers?
own server - latest ubuntu - 4 CPUs XEON 8GB RAM .. 
but performance feels almost the same as on my macbook pro 

> 
> I'm now in the middle of an effort to optimize ruote-sequel (
> https://groups.google.com/d/topic/openwferu-users/ZFfqxAIRgsw/discussion )
> maybe you're using ruote-sequel as well.

do you think ruote-sequel will better perform then redis ?

btw. what is ruote's workitem dispatch frequency? each 0.1 seconds? each 
second?  

> 
> 
>> If it would be possible to reserve workers for specific jobs, we could 
>> ensure the workitems would be processed within time.
>> Or is it possible to give an workitem some kind of priority?
> 
> Sorry, there is no priority for workitems in ruote. The two techniques above
> could be used for prioritizing, but the regular work (outside of participant
> "execution") has to be done as well.
> 

sure, I will give the worker-subclass a try 



> At first, I can help you make it faster (if I know the details).
> 
> 
>> How many workers do you usually run in production?
> 
> In production for now I personnaly only have limited systems with two workers
> and it's more like for backup than for load. One or two new flows per day, a
> bit of activity every 1 or 2 hours. Small office automation.
> 

sounds far less as for what we use it .. .:-/

we have ruote-jobs once a day which will span up to thausends of workitems .. 
but they have no high prio. 

then we have a regular workload of about 1 item per second, sometimes more .. 
for the later I would like to reserve one or more ruote workers ..

thanks a lot for your help so far

> I don't know for others, maybe they'll notice the thread and pass some info.

yes that would be interesting 

ciao, 
Marco 


> 
> 
> Best regards,
> 
> --
> 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


Schöne Grüße Marco


-- 





 
NinjaConcept GmbH
Marco Sehrer
Geschäftsführung
 
Amalienstrasse. 44
76133 Karlsruhe
 
fon:    (+49) 0721 1803523-1
fax:    (+49) 721 961402-99
mobile: (+49) 151 20314416
 
email:  [email protected]
www:    http://www.ninjaconcept.com/




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

<<inline: logo_240x60.gif>>

Reply via email to