服务器为每个客户端发送事件,Puma,Rails和最大专用线程

Question

我正在使用Redis for我的rails项目订阅频道并在事件发生时发布到这些频道.在客户端,我正在注册与这些频道对应的EventSource.每当服务器上的订阅频道发生事件时,服务器执行SSE写入,以便所有已注册的客户端都接收更新.

现在,与订阅这些通道的每个客户端的服务器连接保持活动状态,即专用于此客户端的服务器线程一直运行,直到客户端断开连接.使用这种方法,如果有1000个并发用户订阅了一个频道,我将打开1000个TCP/IP连接.

我正在使用Puma作为本教程中建议的Web服务器.Puma默认指定16个最大线程.我可以将此限制更改为更高的限制.

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

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

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

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

Answer 1

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

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

另一方面，如果它们会不断地访问您的服务器，并且再次轮询数据所需的时间会超过您的数据新鲜度要求，那么您不妨保持连接打开，以避免再次处理整个堆栈。

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