3

I have a class (/lib/updater.rb) that do a large updating of the database (calling external server, calculations,...). Normally this task is called by the cron of the server (rake /lib/tasks/launch_updater.rake that start the updater.rb), but I would like to give the opportunity to start it manually from the client too.

At this moment, from the client, the user can click on a button and launch it in this manner: 

# the controller
Thread.new {
  Updater.start
}

It is a good solution or is better to launch directly from a rake task?

# something like this from the controller
Rake::Task[params[:task]].reenable 
Rake::Task[params[:task]].invoke

The task should be no-blocker (the user should navigate normally on the app without waiting the end of the task).

Which is better and why?

damoiser
  • 6,058
  • 3
  • 40
  • 66
  • 3
    You can do it using delayed job gem. Have a look at this https://github.com/collectiveidea/delayed_job – Arun Aug 29 '13 at 10:14
  • +1 @Arun thanks is a good alternative, but what you think about my 2 solutions? – damoiser Aug 29 '13 at 10:25
  • 1
    IMHO, Thread is not a good idea. Doing it as background job is best for your requirement. Calling rake task in controller is bad practice. – Arun Aug 29 '13 at 11:28
  • 1
    We did something like (pseudocode) `system("bundle exec rake ... --trace >> logfile 2>&1 &")` in a controller when a background job just wasn't an option. It served us well. Remembered I got that from a [railscast](http://railscasts.com/episodes/127-rake-in-background). – Ivo Dancet Sep 21 '13 at 06:37

1 Answers1

0

Working a little on my question I found the following notes:

  • when using a Thread, the CPU used is the same at the CPU of the app (even if you have a multi-core server, the CPU is the same). If you want to use Thread, the Thread task should not be "heavy" or you can go in CPU problems (slow app processing).
  • when you start a Rake task from the terminal or from a server cron, this should take the CPU with the lighter running process. But if you start a task from the application I think the CPU is even here the same of the app.
  • the better solution to work with heavy charge task is to use a delayed service, in this manner the job task should take another CPU than the app's CPU without make problems at the performance of the app:
damoiser
  • 6,058
  • 3
  • 40
  • 66