Hey Keith, thank you for your prompt reply! I am currently experimenting with the devver examples, looks promising so far.
> If you have a process that only knows how to handle, say, outgoing > sms, it should get its own tube (aka queue). > > How are the incoming jobs created? Can you generate them all in the > same format? If so, you could make one incoming tube, and have one > type of worker that handles all incoming jobs, and puts appropriate > outgoing jobs into all three outgoing tubes. I will most probably have one worker per protocol, so that i can handle e.g. incoming rest-calls from sms or twitter via the same worker and xmpp with another. > I have never heard of anyone outgrowing the performance of a single > beanstalkd process on a single box. So, probably, the only reason you > would want more than one is for high availability of the service -- if > a box goes down, you can still submit jobs to the other one. Thats sounds inviting, even if performance is not my main problem. shares an/a few internal ruby queue(s)? > > I'd recommend beanstalkd, but maybe I'm biased. :) Seriously, though, > this is just what beanstalkd was designed for. A textbook example. Thanks for your work! Do you have any tutorial or examples on async_observer and its uses? It seems like a natural fit because I am on RoR or would you start with the plain beanstalk-client gem and later (when?) 'upgrade' to the async_observer? Or use it right away? Did I get it right, that it can make most method calls asynchronous, without any additional work on the backend (just a little config)? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
