ruby-on-rails - 服务器为每个客户端发送事件、Puma、Rails 和最大专用线程

Question

我在 Rails 项目中使用 Redis 订阅 channel 并在事件发生时发布到这些 channel 。在客户端，我正在注册到与这些 channel 相对应的 EventSource。每当服务器上订阅的 channel 发生事件时，服务器都会执行 SSE 写入，以便所有注册的客户端都收到更新。

现在，对于订阅这些 channel 的每个客户端，与服务器的连接保持事件状态，即专用于该客户端的服务器线程一直运行，直到客户端断开连接。使用这种方法，如果有 1000 个并发用户订阅了一个 channel ，我将打开 1000 个 TCP/IP 连接。

我按照 this tutorial 中的建议使用 Puma 作为 Web 服务器. Puma 默认指定 16 个最大线程。我可以将此限制更改为更高的限制。

我可能不知道我的应用程序中一次可能有多少并发用户，也不知道最大数量是多少。我可以在 Puma 中指定的线程数。在最坏的情况下，如果专用于每个并发用户的线程数达到为 Puma 网络服务器指定的最大线程数，则应用程序将为所有用户卡住，直到其中一个并发用户断开连接。

我很高兴使用 Rails 实时流式传输，并且服务器在我的 Rails 项目中发送了事件，但是使用这种方法，我冒着达到 Web 服务器中指定的最大线程限制的风险，因此应用程序对所有用户都没有响应，直到其中一个并发用户断开连接.

对于大型并发用户群，不确定 Puma 的典型最大线程数是多少。

我是否应该考虑其他方法——也许是基于 ajax 的轮询或使用事件驱动、非阻塞 I/O 模型的 Node.js？或者只是运行一些基准测试来了解我的最大线程数是多少？

Answer 1

我实际上正在从事一个项目，由于开放连接问题，我们进行了轮询。我们认为每三秒轮询一次会更容易，然后保持连接打开并挂起。但是数据新鲜度要求不是很严格，三秒，所以是可行的，浪费一个线程三秒有点傻。

因此，除非您对数据新鲜度有非常严格的要求，和/或限制用户群，和/或拥有大量线程的能力，否则定期轮询通常是可行的方法。

另一方面，如果他们要不断地访问您的服务器，并且再次轮询数据需要更长的时间然后您的数据新鲜度要求，您最好保持连接打开以避免再次处理整个堆栈.

同样在 puma 2 中，你也可以在集群模式下运行它，这意味着它会产生一个额外的拥有自己线程的工作人员，你最终可以得到工作人员 X 线程数 = 总线程数。这可能有助于您的计算。

https://github.com/puma/puma#clustered-mode