networking - 如何使 Rails 成为非阻塞的？

Question

我有一个 Rails 应用程序，它偶尔需要根据网络用户点击路由进行非常慢的网络调用(可能永远不会返回)。如果调用比正常情况慢(或不返回)，Rails 似乎会阻塞，不允许发生任何其他事情(我无法打开另一个浏览器并点击不同的路由，我不能使用不同的机器来走不同的路线，什么都没有)。

我尝试使用 Phusion Passenger 来处理多线程(假设这是一个 mongrel 服务器问题)，虽然 Apache 可以处理进入无限循环的测试 Controller (而 Mongrel 不能)，但似乎每一个都是如此通常(当网络调用没有回来时)，它仍然会阻塞。我无法真正复制它，所以它不是那么可测试的:

是 RAILS 本身阻塞了，还是 Apache 不是正确的服务器？如果它是 Rails，我能做些什么来让它在被阻止时向其他用户开放吗？

Answer 1

我们将所有可能需要超过一两秒的调用移至优先队列中以异步处理。我们使用 delayed_job (the collectiveidea branch)处理所有后台作业，但最近越来越流行的另一个是 resque ，我没有使用过它，除了它的基本功能外，我无法谈论它。

从那里您可以使用 ajax 来轮询作业的状态，同时显示进度条或微调器或吃烤土 bean 的 jar 头 - 直到作业完成。这样，后台作业在后台处理，您的 Web 前端将保持快速。

流程是:

1. 用户提交请求
2. 请求排队
3. 前端响应
4. 网络运行开始
5. 网络运行结束
6. 开始对客户进行投票
7. 后台作业完成
8. Poll 获取响应并更新 UI

对比

1. 用户提交请求
2. 网络运行开始
3. 网络运行结束
4. 前端响应

这比您的标准 get/process/display 稍微复杂一点，但是当您有长时间运行的流程时，这是处理它们的理想方法。 Mint.com 就是一个典型的例子。当它更新您的银行账户时，您可以点击整个网站，完成后，您会收到通知。

如果您不能走这条路，那么您只需要增加前端的进程数来处理传入的请求。我们正在迁移到 unicorn但是passenger应该有效地确保您忙碌的员工不会收到新的请求。我建议仅将此作为最后的手段 - 您的请求应在一秒或最多两秒内全部响应，其他所有内容都应转到后台作业处理器。