Rails 应用程序中的长轮询

Question

我有一个应用程序，该应用程序有一个页面，用户必须在该页面上相对实时地查看两个步骤的处理方式。

现在这是由 ajax 短轮询 完成的。我想将其更改为一些不太依赖服务器的技术，我在 Faye gem 和 ajax long-polling 之间进行选择。
Ajax long -polling 更容易实现并且不需要任何服务器入侵。这将需要 4 个 ajax 请求（在 2 个步骤完成时通知页面）。
Faye gem 将需要发送 3 个请求，这并不少。而且它需要我设置我的 nginx-passenger 服务器，并且通常更难实现和支持。

我会选择 ajax long-polling，但我听说它需要在长轮询请求时运行整个 Rails 实例，这会耗尽我的 RAM。 另一方面，从How rails server on production works? 我了解到 Rails 的 long-polling 可能没有这个问题。那么，什么是真实的， - 来自多个客户端的 ajax 长轮询 是否需要许多并发应用程序处理（这可能会过度分配我的一些资源，不确定是哪个）？

Answer 1

您的问题提出了三种不同技术的可能性：

• Websockets（Faye、Iodine、EM-Websockets 或任何您喜欢的 Websocket 解决方案）。
• 短轮询（基于客户端的“拉”式通知）。
• 长轮询（客户端和服务器尝试持久连接 - 之前的 websockets 技术）。

虽然 Websockets 似乎是最可扩展和最自然的推送通知解决方案，但它 - 就像大多数事情一样 - 是一个特定于应用程序的问题。您需要考虑您的资源和需求，并以最佳方式平衡它们。

Websockets 与 Short-polling 各有一个“价格”。虽然 Short-Polling 更容易实现，但 Websocket 允许真正的“推送”，并且它们的设计旨在节省 Web 和服务器资源。

至于 Websockets 与长轮询，答案很简单——Websockets 会更有效率。

长轮询模拟通过阻止浏览器发送的 HTTP 请求直到服务器有数据要“回答”的持久连接。如果并发无效，这可能会阻塞整个服务器，并且显然会阻塞负责响应请求的线程（服务器的线程池中有多少线程？8？24？）。

相比之下，Websockets 是不阻塞但与服务器集成的持久连接。这是一个更加优雅和资源友好的解决方案。

您可以在此处找到有关长轮询与短轮询的更多信息：

• Short-polling vs Long-polling for real time web applications?

• Scaling a chat app - short polling vs. long polling (AJAX, PHP)

举例：

假设您预计在任何特定时刻有 5,000 个活跃客户连接到您的网站（如果每个客户每天花费 30 分钟连接，这假设总共有大约 240,000 个客户，不考虑高峰和低谷是使用时间)。

现在，让我们比较一下应用程序中 push/update 部分的资源：

• Short Polling：如果每个客户端每 2 秒发送一次更新查询（不算快，但也不算太慢，取决于您的需要），您需要每秒处理 2,500 个请求才能回答更新查询请求。每个请求都会影响您应用的内存、性能和响应能力。

• 长时间轮询：您将有 5000 个连接阻塞并等待响应。那是 5,000 个任务，每个任务可能会占用一个线程……即使您设法使用一些异步响应和线程池（这对于 Rack 服务器来说非常困难）来循环任务，您也会消耗 CPU 和内存等待更新。此外，每次更新都需要您更新 5,000 个连接（或者，如果幸运的话，HTTP/1.1 的keep-alive 功能将使您免于这种不便）。这些阻塞的连接将影响您的应用程序的响应能力和性能，使用 CPU 周期并从实际请求中集中注意力。它可能（或可能不会）比尝试每秒回答 2,500 个请求更好......但不是很有效。推送数据是即时的。

• Websockets：您将有 5,000 个连接添加到服务器的 IO reactor。只要有任何活动（可能永远不会发生）并且没有任何线程被阻塞，就会调用 websocket 回调。使用 websocket 连接发送的更新不会导致连接关闭，因此无需在每次更新时更新连接。推送数据是即时的。

总结：

按照设计，如果您有自己的服务器，那么使用 Websockets 比使用短轮询或长轮询时，您应该能够为更多的客户端提供服务。

但是：

1. Websockets（以及长轮询）比短轮询更难编码（它们使用非常宝贵的资源，即人类编码时间）；

2. 一些托管服务（即 Heroku）将限制 websocket 客户端的数量，使“数学”不太确定……另一方面，这些相同服务的并发限制（请求/秒）可能最终会支持网络套接字。