Rails 3.1/rake - datespecific tasks without queues

Question

I want to give my users the option to send them a daily summary of their account statistics at a specific (user given) time ....

Lets say following model:

class DailySummery << ActiveRecord::Base
  # attributes:
  # send_at
  # => 10:00 (hour)
  # last_sent_at
  # => Time of the last sent summary
end

Is there now a best practice how to send this account summaries via email to the specific time?

At the moment I have a infinite rake task running which checks permanently if emails are available for sending and i would like to put the dailysummary-generation and sending into this rake task.

I had a thought that I could solve this with following pseudo-code:

while true
  User.all.each do |u|
    u.generate_and_deliver_dailysummery if u.last_sent_at < Time.now - 24.hours
  end
  sleep 60
end

But I'm not sure if this has some hidden caveats...

Notice: I don't want to use queues like resq or redis or something like that!

EDIT: Added sleep (have it already in my script)

EDIT: It's a time critical service (notification of trade rates) so it should be as fast as possible. Thats the background why I don't want to use a queue or job based system. And I use Monit to manage this rake task, which works really fine.

Answer 1

There's only really two main ways you can do delayed execution. You run the script when an user on your site hits a page, which is inefficient and not entirely accurate. Or use some sort of background process, whether it's a cron job or resque/delayed job/etc.

While your method of having an rake process run forever will work fine, it's inefficient because you're iterating over users 24/7 as soon as it finishes, something like:

while true
    User.where("last_sent_at <= ? OR last_sent_at = ?", 24.hours.ago, nil).each do |u|
            u.generate_and_deliver_dailysummery
    end

    sleep 3600
end

Which would run once an hour and only pull users that needed an email sent is a bit more efficient. The best practice would be to use a cronjob though that runs your rake task though.

Answer 2

Running a task periodically is what cron is for. The whenever gem (https://github.com/javan/whenever) makes it simple to configure cron definitions for your app.

As your app scales, you may find that the rake task takes too long to run and that the queue is useful on top of cron scheduling. You can use cron to control when deliveries are scheduled but have them actually executed by a worker pool.

Answer 3

I see two possibilities to do a task at a specific time.

Background process / Worker / ...

It's what you already have done. I refactored your example, because there was two bad things.

1. Check conditions directly from your database, it's more efficient than loading potential useless data
2. Load users by batch. Imagine your database contains millions of users... I'm pretty sure you would be happy, but not Rails... not at all. :)

Beside your code I see another problem. How are you going to manage this background job on your production server? If you don't want to use Resque or something else, you should consider manage it another way. There is Monit and God which are both a process monitor.

while true
  # Check the condition from your database
  users = User.where(['last_sent_at < ? OR created_at IS NULL', 24.hours.ago])
  # Load by batch of 1000
  users.find_each(:batch_size => 1000) do |u|
     u.generate_and_deliver_dailysummery
  end
  sleep 60
end

Cron jobs / Scheduled task / ...

The second possibility is to schedule your task recursively, for instance each hour or half-hour. Correct me if I'm wrong, but do your users really need to schedule the delivery at 10:39am? I think that let them choose the hour is enough.

Applying this, I think a job fired each hour is better than an infinite task querying your database every single minute. Moreover it's really easy to do, because you don't need to set up anything.

There is a good gem to manage cron task with the ruby syntax. More infos here : Whenever

Answer 4

You can do that, you'll need to also check for the time you want to send at. So starting with your pseudo code and adding to it:

while true
  User.all.each do |u|
    if u.last_sent_at < Time.now - 24.hours && Time.now.hour >= u.send_at
      u.generate_and_deliver_dailysummery
      # the next 2 lines are only needed if "generate_and_deliver_dailysummery" doesn't sent last_sent_at already
      u.last_sent_at = Time.now  
      u.save
    end
  end

  sleep 900
end

I've also added the sleep so you don't needlessly hammer your database. You might also want to look into limiting that loop to just the set of users you need to send to. A query similar what Zachary suggests would be much more efficient than what you have.

Answer 5

If you don't want to use a queue - consider delayed job (sort of a poor mans queue) - it does run as a rake task similar to what you are doing

• https://github.com/collectiveidea/delayed_job
• http://railscasts.com/episodes/171-delayed-job

it stores all tasks in a jobs table, usually when you add a task it queues it to run as soon as possible, however you can override this to delay it until a specific time

you could convert your DailySummary class to DailySummaryJob and once complete it could re-queue a new instance of itself for the next days run

Answer 6

How did you update the last_sent_at attribute?

if you use

last_sent_at += 24.hours  

and initialized with last_sent_at = Time.now.at_beginning_of_day + send_at

it will be all ok .

don't use last_sent_at = Time.now . it is because there may be some delay when the job is actually done , this will make the last_sent_at attribute more and more "delayed".