使用delayed_job 和运行rails 控制台有什么区别答案

【问题标题】：What's the difference between using a delayed_job and running rails console使用delayed_job 和运行rails 控制台有什么区别
【发布时间】：2012-12-03 20:02:50
【问题描述】：

我需要在服务器端完成一个长时间运行的爬行任务，所以我尝试使用delayed_job，但是，我在使用delayed_job 和Capybara 时遇到了问题。所以，我改为在rails console 中运行任务。由于这是一项漫长的任务，所以当我的ssh 连接断开时，我使用tmux 来保持我的rails console 活动。

我知道使用tmux 实际上是在模仿我使用rails console。所以我的问题是，运行delayed_job 和在rails console 中执行任务之间有真正的区别吗？

与delayed_job 相比，在rails console 中运行长任务是否会占用机器上的更多资源，因为它在前台运行？

在tmux 上运行rails console 是否成为后台服务？因为我可以让它自己运行。

谢谢。

【问题讨论】：

标签： ruby ruby-on-rails-3 delayed-job tmux rails-console

【解决方案1】：

delayed_job 允许自动执行任务，而不是通过登录服务器在控制台中手动执行任务。

如果您可以手动执行任务，那么不必担心使用delayed_job/resque 或the other background processing tools 中的任何一个来自动执行它。

这很可能是您想要定期完成的任务，因此将其作为后台任务自动化是值得的。（可能值得花时间找出延迟作业/水豚错误）

当前在服务器上的 tmux 会话中运行任务的解决方案是模拟后台进程（手动启动的）

【讨论】：