延迟工作，Rails和Mandrill的预期行为是？ [英] Is this expected behaviour for Delayed Job, Rails and Mandrill?

问题描述

与相关这个问题解释了控制器逻辑的起源，我在将延迟作业推送到github并重新部署之前有一个关于后台作业的问题。

Related to this question, which explains the origins of the logic in the controller, I have a question about background jobs with Delayed Job before pushing it to github and re-deploying.

模型和范围工作，控制器中的逻辑工作，电子邮件 text.erb 文件中的条件工作，用户是读者或订阅者，可以设置他们的e邮件偏好在他们的我的帐户页面：[文章&更新，正文，无电子邮件等]。延迟作业在后台进行设置和处理，使前端可以一如既往的轻松快捷，Mandrill SMTP正确接收并快速发送电子邮件。

The model and scopes work, the logic in the controller(s) works, the conditionals in the e-mail text.erb files work, users are either readers or subscribers and can set their e-mail preferences on their "My Account" page: [Articles & Updates, Just Articles, No E-mail, etc.]. Delayed Job is set up and processing it all in the background, making the front end nice and fast as always, and Mandrill SMTP is receiving it all correctly and sending out the e-mails in a speedy manner.

article_controller 中的主逻辑块可将正确的电子邮件发送给正确的用户：

The main logic block in article_controller does this to send the right e-mails to the right users:

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然后为每个这样做：

Looking at the Rails and Delayed Jobs logs, though, with a test set of just a few users (5-10), when it cycles through the logic and decides three e-mails need to be sent out, Rails is doing three INSERT INTO the DJ table and DJ then does this for each one:

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

然后当它完成后，它报告回来：

And then when it has finished, it reports back with:

3 jobs processed at 0.9039 j/s, 0 failed

在Mandrill日志中，每个发送的电子邮件都会获得自己的API成功/失败条目。

And in the Mandrill logs, each e-mail sent gets its own API "success/fail" entry.

所以：延迟作业是否正确/预期的行为？应该为每个电子邮件创造一份工作吗？或者以不同的方式处理它们？这样做的方式是打破服务器，当我们开始做X000而不是十/三？

So: is this correct/expected behaviour for Delayed Job? Should it be creating one job for each e-mail? Or processing them in a different way? Is this way of doing things going to break the server when we start doing X thousand instead of ten/three?

推荐答案

像 delayed_job 的默认行为。您有 ArticleMailer.delay 调用3次，并将其全部排队，因此您会看到 3个作业处理。

This looks like the default behaviour of delayed_job. You have ArticleMailer.delay call 3 times and it queues them all and hence you see 3 jobs processed.

我想，你还应该看看 handle_asynchronously 功能 delayed_job

I think, you should also look at handle_asynchronously feature of delayed_job.

此外，如果您打算处理大量电子邮件，我建议您探索其他选项，例如 Resque 或 sidekiq 或< a href =https://github.com/kr/beanstalkd =nofollow noreferrer> beanstalkd

Also, if you plan to process a huge number of emails, I would suggest you to explore other options such as Resque or sidekiq or beanstalkd

他们比 delayed_job 在处理大量工作时。 delayed_job 简单易用，但可以面对性能问题。

They are better than delayed_job when it comes to process a lot of jobs. delayed_job is simple and easy to setup, but can face performance issue in scale.

请参阅此了解一下。

这篇关于延迟工作，Rails和Mandrill的预期行为是？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！