Ich entwickle eine Rails 3.2.16-App und stelle sie auf einem Heroku-Dev-Account mit einem kostenlosen Web-Dyno und keinen Worker-Dynos bereit. Ich versuche festzustellen, ob ein (bezahlter) Arbeiterprüfstand wirklich benötigt wird.

Die App verschickt verschiedene E-Mails. Ich benutze delayed_job_active_record, um diese in die Warteschlange zu stellen und sie zu versenden.

Ich muss auch jede Minute eine Benachrichtigungsanzahl überprüfen. Dafür benutze ich Rufus-Scheduler.

rufus-scheduler scheint in der Lage zu sein, eine Hintergrundaufgabe / einen Thread auszuführeninnerhalb ein Heroku-Webdyno.

Andererseits zeigt alles, was ich auf delayed_job finden kann, dass es einen separaten Arbeitsprozess erfordert. Warum? Warum kann delayed_job nicht dasselbe tun, wenn rufus-scheduler einen Daemon innerhalb eines Web-Dynos ausführen kann?

Ich habe Folgendes getestet, um meine minutengenaue Aufgabe auszuführenund delayed_jobs abarbeiten, und es scheint innerhalb des Heroku-Webdynos zu funktionieren:

config / initializers / rufus-scheduler.rb

require 'rufus-scheduler'
require 'delayed/command'

s = Rufus::Scheduler.singleton
s.every '1m', :overlap => false do # Every minute
  Rails.logger.info ">> #{Time.now}:  rufus-scheduler task started"
  # Check for pending notifications and queue to delayed_job
  User.send_pending_notifications
  # work off delayed_jobs without a separate worker process
  Delayed::Worker.new.work_off  
end

Das scheint so offensichtlich, dass ich mich frage, ob ich etwas verpasse? Ist dies eine akzeptable Methode, um die Warteschlange delayed_job ohne die zusätzliche Komplexität und die Kosten eines separaten Arbeitsprozesses zu handhaben?

Aktualisieren

Wie @jmettraux hervorhebt, wird Heroku nach einer Stunde einen inaktiven Webdyno inaktivieren. Ich habe es noch nicht eingerichtet, aber nehmen wir an, dass ich eine der verschiedenen Keep-Alive-Methoden verwende, um zu verhindern, dass es schläft:Einfache Möglichkeit, Heroku Leerlauf zu verhindern?.