[LRUG] Distributed delayed_job / resque

Glenn Gillen glenn at rubypond.com
Tue Jul 3 09:01:23 PDT 2012


I've used them both in a distributed fashion.

Resque - Worked better of the two when there were a hundred or so workers attached. My only problem with it is that it's not guaranteed to be durable. So if my Redis instance dies/restarts/whatever I need to be able to rebuild the queue. Easy enough done, just be mindful of it.
DJ - Meh. Ran into problems under heavy load. Ensuring failed jobs were removed and that there was proper indexing on the priority, run_at, etc. fields improved the situation. 

I've been queue_classic for a number of months now without issue. It uses the NOTIFY event within postgres to hand work out to workers. For some reason I have more faith in something implemented at the DB level to work when I need it most.

G


On Jul 3, 2012, at 8:30 AM, Ed James (Alt) wrote:

> Hi all
> 
> I've used both DJ and Resque before, so I'm familiar with both. However, I've never used them in a distributed architecture, where you have workers running on multiple machines. Resque seems to tout this as a feature a bit more then DJ, although the DJ docs say it is possible.
> 
> Has anyone had any experience in running either Resque or DJ in a distributed setup?
> 
> The primary reason for wanting to do this is for the ability to auto-scale (on AWS).
> 
> Thanks.
> 
> -- 
> Ed James
> Sent with Sparrow
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20120703/9d111ac2/attachment-0003.html>


More information about the Chat mailing list