这是延迟作业、Rails和Mandrill的预期行为吗?

与相关 this question ,这解释了控制器中逻辑的起源,在将其推到github并重新部署之前,我对延迟作业的后台作业有一个疑问。

模型和范围工作,控制器中的逻辑工作,电子邮件中的条件 文本.erb 文件有效,用户可以是读者或订阅者,可以在“我的帐户”页面上设置电子邮件首选项:[文章和更新,仅文章,无电子邮件等]。延迟作业是在后台设置和处理的,使前端一如既往地漂亮和快速,而Mandrill SMTP正在正确接收并以快速的方式发送电子邮件。

中的主逻辑块 条款_控制器 这样做是为了向正确的用户发送正确的电子邮件:

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正在对DJ表进行三次INSERT,然后DJ对每一封进行如下操作:

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

然后,当它完成后,它会返回报告:

3 jobs processed at 0.9039 j/s, 0 failed

在Mandrill日志中,发送的每个电子邮件都有自己的API“成功/失败”条目。

那么:延迟工作的这种行为是否正确/预期?是否应该为每个电子邮件创建一个作业?或者以不同的方式处理它们?当我们开始做X千而不是十/三时,这种做法会破坏服务器吗?