我有一个应用程序，有一个页面，用户必须看到在相对实时的2步是如何处理的。
现在这是通过ajax短轮询完成的。我想将其更改为一些较少的服务器重技术，我选择Faye gem和ajax长轮询。
Ajax长轮询更容易实现，不需要任何服务器入侵。这将需要4个ajax请求(对于页面通知2步完成)。
Faye gem将发送3个请求，这并不是很多。而且它需要我设置我的nginx-passenger服务器，并且通常更难实现和支持。
我将选择ajax长轮询，但我听说它将需要一个完整的Rails实例运行，而请求是长轮询，这将耗尽我的RAM。另一方面，rails服务器在生产环境中是如何工作的?我知道Rails对于长轮询可能没有这个问题。那么，来自多个客户机的ajax长轮询是否需要许多并发应用程序处理(这可能会过度分配我的一些资源，不确定是哪一个)?
你的问题提出了三种不同技术的可能性:
- Websockets (Faye，碘，EM-Websockets或任何你喜欢的websocket解决方案)。
- 短轮询(基于客户端的'pull'风格通知)。
- 长轮询(客户端和服务器尝试持久连接- pre - websockets技术)。
虽然Websockets似乎是最具扩展性和最自然的推送通知解决方案，但它是——正如大多数事情一样——一个特定于应用程序的问题。你需要考虑你的资源和你的需求，并以最好的方式平衡它们。
Websockets和Short-polling都有各自的"价格"。虽然短轮询更容易实现，但Websockets允许真正的"推送"。他们的设计是为了节约网络和服务器资源。
关于Websockets与长轮询的比较，答案很简单——Websockets将更有效。
长轮询通过阻止浏览器发送的HTTP请求来模拟持久连接，直到服务器有数据可以"应答"为止。与。如果并发性不有效，这可能会阻塞整个服务器，并且显然会阻塞负责响应请求的线程(服务器的线程池中有多少线程?)8？ 24 ?)。
相反，Websockets 是持久连接，它不阻塞，而是与服务器集成。这是一个更加优雅和资源友好的解决方案。
您可以在这里找到关于长轮询与短轮询的更多信息:
-
短轮询vs长轮询实时web应用程序?
-
扩展聊天应用程序-短轮询vs.长轮询(AJAX, PHP)
:
让我们假设你期望有5000个活跃的客户端随时连接到你的网站(如果每个客户端每天花费30分钟连接，这假设总共有240K个客户端，不考虑使用时间的高峰和低谷)。
现在，让我们比较应用程序的push/update部分的资源:
短轮询:如果每个客户端每2秒发送一个更新查询(不是很快，但也不是太慢，取决于您需要什么)，您需要处理2500个请求/秒，仅用于回答更新查询请求。每个请求都会影响应用程序的内存、性能和响应能力。
长轮询:您将有5000个连接阻塞并等待响应。这是5000个任务，每个任务可能会占用一个线程……即使您设法使用一些异步响应和线程池来循环任务(这对于机架服务器来说是非常困难的)，您也将消耗CPU和内存来等待更新。此外，每次更新都需要您更新5,000个连接(或者，如果您幸运的话，HTTP/1.1的
keep-alive功能将为您省去这种不便)。这些阻塞的连接将影响应用程序的响应性和性能，占用CPU周期并从实际请求中获取焦点。这可能(也可能不是)比尝试响应每秒2500个请求要好……但不是很有效。Websockets:您将有5,000个连接添加到服务器的IO反应器。websocket回调将在任何活动(可能永远不会发生)并且没有线程被阻塞时被调用。使用websocket连接发送的更新不会导致连接关闭，因此不需要在每次更新时更新连接。
:
根据设计，如果你有自己的服务器，你应该能够使用Websockets服务更多的客户端，而不是使用短轮询或长轮询。
然而:Websockets(以及长轮询)比短轮询更难编码(它们使用非常宝贵的资源，即人类编码时间);
一些托管服务(例如Heroku)将限制websocket客户端计数，使"数学";不太确定……另一方面，这些服务的并发限制(req/sec)可能最终会有利于websockets。