BackgrounDRb best practises

  • Best place for BackgrounDRb documentation is the README file that comes with the plugin. Read it thoroughly before going anywhere else for documentation.
  • When passing arguments from Rails to BackgrounDRb workers, don’t pass huge ActiveRecord objects. Its asking for trouble. You can easily circumvent the situation by passing id of AR objects.
  • Its always a good idea to run trunk version rather than older tag releases.
  • To debug backgroundrb problems. Its always a good idea to start bdrb in foreground mode by skipping ‘start’ argument while starting the bdrb server. After that, you should fire rails console and try invoking bdrb tasks from rails console and find out whats happening. John Yerhot has posted an excellent write up about this, here
  • Whenever you update the plugin code from svn, don’t forget to remove old backgroundrb script and run :
     rake backgroundrb:setup
  • When deploying the plugin in production, please change backgroundrb.yml, so as production environment is loaded in backgroundrb server. You should avoid keeping backgroundrb.yml file in svn. Rather, you should have a cap task that generates backgroundrb.yml on production servers.
  • When you are processing too many tasks from rails, you should use inbuilt thread pool, rather than firing new workers
  • BackgrounDRb needs Ruby >= 1.8.5
  • When you are starting a worker using

    from rails and using a job_key to start the worker ( You must use unique job keys anyways, if you want more than one instance of same worker running at the same time ), you must always access that instance of worker with same job key. Thats all MiddleMan methods that will invoke a method on that instance of worker must carry job_key as a parameter. For example:

       session[:job_key] = MiddleMan.new_worker(:worker => :fibonacci_worker, :job_key => 'the_key', :data => params[:input])
       MiddleMan.send_request(:worker => :fibonacci_worker, :worker_method => :do_work, :data => params[:input],:job_key => session[:job_key])

    Omitting the job_key in subsequent calls will be an error, if your worker is started with a job_key.

11 thoughts on “BackgrounDRb best practises”

  1. Thanks – this is very helpful. What would you say is a good metric for how many tasks from rails is too many? Should most apps be designed using thread_pool from the beginning, or should we start by firing new workers and wait until it appears too many workers are being spawned to switch to thread_pool?

  2. Generally for similar tasks you should have one worker to handle them and only one instance of the that worker should be active/running at a time. Now, if tasks that are being invoked are getting overlapped, as in request for next task comes before first one is finished, you should consider using thread_pool rather than creating new worker.

  3. Hi Hemant

    great work on backgroundrb … I have been using it in many projects including where it handles mp3 encoding after an upload.

    The new backgroundrb site is cool but i just can’t find the link to the documentation (rdoc) .. you may want to fix that

    also as u say, readme is a great place to start, but the current readme file does not have much information.

    Once again .. thanks for keeping this great plugin in constant development

    Prateek Dayal

  4. Nice work Hemant.

    Is the part on backgroundrb caching on this page still relevant or is that as well outdated?

    If it is outdated then where can I get some information on backgroundrb caching? or may be you could do a quick write up on that too 😉

    Thanks in advance and keep up the good work.

Leave a Reply

Your email address will not be published. Required fields are marked *