Является ли это ожидаемым поведением для Delayed Job, Rails и Mandrill?

Question

Связано с this question, в котором объясняется происхождение логики в контроллере, у меня есть вопрос о фоновых заданиях с Delayed Job, прежде чем нажимать его на github и повторно развертывать.

Модели и телескопы работа, логика в контроллере (ы) работает, то условные в электронной почте text.erb файлов работают, пользователи либо читатели или подписчики и могут установить их по электронной почте на предпочтения их страница «Моя учетная запись»: [Статьи & Обновления, только статьи, нет электронной почты и т. д.]. Задержанное задание настроено и обрабатывает все это в фоновом режиме, делая фронт хорошо и быстро, как всегда, и Mandrill SMTP получает все правильно и быстро отправляет электронные письма.

Основной логический блок в article_controller делает это, чтобы послать правильные электронные письма нужных пользователей:

if @article.update(article_params) && @article.status == 'published' && @article.created_at.today? 
    User.wantsarticles.editor.each do |user| 
     ArticleMailer.delay.send_article_full(@article, user) 
    end 
    User.wantsarticles.subscribers.each do |user| 
     ArticleMailer.delay.send_article_full(@article, user) 
    end 
    User.wantsarticles.readers.each do |user| 
     ArticleMailer.delay.send_article_teaser(@article, user) 
    end 
    format.html { redirect_to :action => 'admin', notice: 'Article was successfully updated.' } 
    format.json { render :show, status: :ok, location: @article } 
    else 
     format.html { redirect_to :action => 'admin', notice: 'Article was successfully updated.' } 
     format.json { render :show, status: :ok, location: @article } 
    end 

Глядя на журналы Rails и отложенной Работа, хотя, с тестовым набором только несколько пользователей (5-10), когда он циклически проходит логику и решает, что нужно отправить три письма, Rails делает три INSERT INTO таблицы DJ, а DJ делает это для каждого из них:

Job NewsitemMailer.send_article_full (id=21) RUNNING 
Job NewsitemMailer.send_article_full (id=21) COMPLETED after 0.8950 

И затем, когда он закончит, i т сообщает назад с:

3 jobs processed at 0.9039 j/s, 0 failed 

И в журналах Mandrill, каждый электронной почты, отправляемой получает свой собственный API «/ не успех» входа.

Итак: это правильное/ожидаемое поведение для Задержанного задания? Должна ли быть создана одна работа для каждого электронного письма? Или обрабатывать их по-другому? Является ли этот способ делать вещи, чтобы сломать сервер, когда мы начинаем делать X тысяч вместо десяти/трех?

Answer 1

Это похоже на поведение по умолчанию delayed_job. У вас есть ArticleMailer.delay звоните 3 раза, и он ставит их в очередь, и вы видите 3 jobs processed.

Я думаю, вы также должны посмотреть handle_asynchronously особенность delayed_job.

Кроме того, если вы планируете обрабатывать огромное количество писем, я хотел бы предложить вам изучить другие варианты, такие как Resque или sidekiq или beanstalkd

Они лучше, чем delayed_job, когда дело доходит до обработки много рабочих мест , delayed_job прост и прост в настройке, но может столкнуться с проблемой производительности в масштабе.

См. this, чтобы получить обзор.