ruby-on-rails – 在Rails应用程序中进行长轮询

> Websockets(Faye,Plezi,EM-Websockets或您喜欢的任何websocket解决方案).
>短轮询(基于客户端的’拉’式通知).
>长轮询(客户端和服务器尝试持久连接 – 前webockets技术).

虽然Websockets似乎是推送通知最具扩展性和自然性的解决方案,但它 – 大多数情况下 – 都是一个特定于应用程序的问题.您需要考虑您的资源和需求,并以最佳方式平衡它们.

Websockets与Short-polling各自带有“价格”.虽然短轮询更容易实现,但Websockets允许真正的“推送”,其设计旨在节省Web和服务器资源.

至于Websockets与Long轮询,答案很简单 – 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分钟连接,则假定总共约240K客户端,忽略峰值和退潮是使用时间).

现在,让我们比较应用程序的推送/更新部分的资源：

>短轮询：如果每个客户端每2秒发送一次更新查询(不是很快,但不是太慢,具体取决于您的需要),您需要处理2,500个请求/秒才能回答更新查询请求.每个请求都会影响应用的内存,性能和响应能力.
>长轮询：您将阻止5000个连接并等待响应.那5000个任务可能每个都使用一个线程……即使你设法使用一些异步响应和一个线程池来循环任务(这对于Rack服务器来说非常困难),你会耗费CPU和内存等待更新.此外,每次更新都需要您续订5,000个连接(或者,如果幸运的话,HTTP / 1.1的保持活动功能将为您免除这种不便).这些被阻止的连接将影响应用程序的响应能力和性能,使用CPU周期并从实际请求中获得焦点.它可能(或可能不)比尝试每秒回答2,500个请求更好……但效果不是很好.立即推送数据.
> Websockets：您将有5,000个连接添加到服务器的IO reactor.只要有任何活动(可能永远不会发生)并且没有任何线程被阻止,将调用websocket回调.使用websocket连接发送的更新不会导致连接关闭,因此无需每次更新都更新连接.立即推送数据.

总结：

按照设计,如果您有自己的服务器,那么您应该能够使用Websockets服务更多客户端,而不是使用Short或Long轮询.

然而：

> Websockets(以及长轮询)比短轮询更难编码(它们使用非常有价值的资源,这是人类编码时间);>一些托管服务(即Heroku)将限制websocket客户端数量,使“数学”不太确定……另一方面,这些相同服务的并发限制(req / sec)可能最终有利于websockets.