From: Ezra Zygmuntowicz <ezmobius@...>
Date: 2007-05-28T06:14:10+09:00
Subject: Re: BackgrounDRb Theory


On May 27, 2007, at 1:56 PM, Sy Ys wrote:

> Ezra Zygmuntowicz wrote:
>>   Yeah I have the best luck with backgroundrb when I run a set number
>> of immortal workers that just loop and pull jobs from a queue.
>
> How is this different from B? Why would rq be necessary for this?
>
> --  
> Posted via http://www.ruby-forum.com/.
>

B) Instantiate a new worker which will run every 24 hours after a person
signs up. I like this because it eliminates the spike but still updates
everyone. But I'm not sure what effect having an worker running for each
user will have on server memory.


	you definitely don't want one worker running for each user. Each  
worker is a new process and takes up resources. Try it first with  
just one worker that gets started on bdrb server start and loops,  
works on jobs in the queue, then sleeps and does it again.

	Here is a simple example, you may want to add a pending and executed  
flag to the queue items.:

class PublishWorker < BackgrounDRb::Worker::Base
   def do_work(args={})
     loop do {
       urls_to_publish = PublishQueue.find(:all, :limit => 20)
       urls_to_publish.each do |url|
          # code here to work with urls
       end
       sleep args[:sleep]
     }
   end
end

PublishWorker.register


Cheers-


-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)