我们正在对一个新应用进行一些原型(prototype)设计，并注意到其中一个操作需要很长时间才能加载(80-120 秒)。由于很多处理不需要在页面加载时发生(我们可以稍后通过 Ajax 请求数据)，我想到了使用 Process.fork 让页面立即返回，而处理仍在“幕后”进行。
我们将 Apache 与 Passenger 一起用于该应用程序。
一些事情:
我了解 delayed_jobs、resque、BJ 和其他后台作业 gem。我们使用 dj，最终也会为此使用类似的东西。这是我们制作原型(prototype)时的权宜之计。
我不关心服务器性能。该应用在自己的服务器上运行，只有少数用户试用。
早期测试表明这很好用，但我想知道使用它是否是个好主意。它会可靠吗？如果用户导航到另一个页面或关闭选项卡/浏览器， fork 进程是否会继续？ fork完成后，进程会自行终止吗？
最佳答案
取决于“处理”的含义。 通常，如果处理意味着使用 Rails 堆栈，这将不可靠 - 因为请求释放的主进程可能会被乘客分配给另一个请求，并且事情可能会出错。 此外，Passenger 可能会在某些情况下关闭主进程，从而关闭 Rails 实例(减少空闲实例池等)。
通常这可能会导致进程泄漏、意外锁定、竞争条件、关闭时应用程序错误等。
我建议使用在 Apache/Passenger 堆栈之外运行的 worker，例如使用集群 BackgrounDRb或其他解决方案(您提到了 Resque)。
还有另一个想法，我目前将其用于我的应用程序的 cron 作业。我的 crontab 只是一些 wget 来执行长时间运行的任务。您可以使用 OpenURI 在 ruby fork 中做类似的事情一经请求。想象一下应用程序通过 HTTP ping 自身。 fork 进程不再需要 Rails - 它只是访问任务页面，下一个 Passenger 服务请求并管理这个特殊请求的应用程序实例。
万一 Passenger 杀死了 fork 的父级并因此 fork 了进程 - 另一个 Rails 实例应该继续处理 http 请求。
关于ruby-on-rails - Rails Controller 中的 Process.fork，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3984748/