短轮询与长轮询实时Web应用程序？
我正在构build一个实时的Web应用程序据我所知，最受欢迎的select是短轮询和长轮询。 衡量一个在另一个之间有什么优点和缺点？
-
短轮询（aka AJAX定时器）：
优点：更简单，而不是服务器消耗（如果请求之间的时间很长）。
缺点：如果需要得到通知，服务器事件发生时不会有任何延迟。 示例 （基于ItsNat ） -
长期投票（又名基于XHR的Comet）
优点：当服务器事件发生时，您会收到通知。 缺点：使用更复杂，更多的服务器资源。 示例 （基于ItsNat）
只是为了争论。
两者都是http请求（xhr），它至less部分不真实，它使用更多的服务器资源（完全依赖于技术，稍后将解释）。
短轮询。
很多请求在服务器上处理。 创build大量的stream量（使用资源，但是一旦回复就释放）：
00:00:00 C-> Is the cake ready? 00:00:01 S-> No, wait. 00:00:01 C-> Is the cake ready? 00:00:02 S-> No, wait. 00:00:02 C-> Is the cake ready? 00:00:03 S-> Yeah. Have some lad. 00:00:03 C-> Is the other cake ready? .. 长期投票
一个请求去服务器和客户端正在等待响应来（它未解决）。 在服务器与PHP / Apache的情况下，将意味着一个产生的线程来处理，预留资源，直到它完成。 所以stream量比较小，但是你很快就吃掉了你的资源（或者说你阻止了资源）。 但是，如果您使用Node（或其他任何asynchronous方法（例如c ++ qt）），则可能会最大限度地减less资源使用（存储http请求的响应对象，并在工作准备就绪时使用它）
12:00 00:00:00 C-> Is the cake ready? 12:00 00:00:03 S-> Yeah.Hame some lad. 12:00 00:00:03 C-> Is the cake ready?
如果你把它和短轮询进行比较，你会发现可能在短时间的轮询中你使用了更多的轮询，但是在那3秒内，你实际上需要1,5个处理时间（意味着在你的呼叫之间可以执行一些操作）。 在长时间轮询的情况下，始终使用相同的资源。 现在通常PHP的所有库都以4MB内存开始 – 然后你有一个4-20MB的框架。 假设你有1024MB的RAM（免费）。 说让我们悲观，并假设你将使用每个php instace 25 MB。 这意味着您只能获得多达40个长轮询连接脚本。
正因为如此，你可以使用Node进行更多的服务，因为节点不会产生实例（除非你想使用工人等），所以使用相同的内存，你可能很容易就可以轻松地连接10k个连接。 你会得到一个尖峰在CPU，因为他们会来，当他们将有可能被释放，但是当他们闲置，就像他们不存在（你只支付内存结构，你会保留在节点/ C + +）。
的WebSocket
现在，如果你想发送很less的东西，无论什么时候进出客户端，请去websockets（ws协议）。 第一次调用是http请求的大小，但稍后您只发送消息，从客户端到服务器（新问题）和服务器到客户端（回答或推送 – 甚至可以为所有连接的客户端进行广播）。 有php websocekts库，但同样，使用一些不同的技术节点或C + +优选。
一些libs，比如socket.io有自己的层次结构，所以当websocket失败时，它会回到长轮询或短轮询。
何时使用。
短投票 – 好吧，从来没有^^。
长时间轮询 – 可能在与服务器交换单个呼叫时，服务器在后台执行一些工作。 此外，当你不会在同一页面上查询服务器了。 此外，当你不使用PHP作为层来处理长轮询连接（节点/ C + +可以是一个简单的中间层）。 注意长时间轮询可能是非常有益的，但只有当你这样做的时候。
Websocket – 你可能会用服务器交换一两个电话，或者可能来自你没有预料到/要求的服务器，比如电子邮件通知或其他东西。 你应该计划不同的“房间”，取决于function。 拥抱javascript的基于事件的本质;]
如果你想获得基于数据库的实时应用程序，你可以使用Ajax长轮询和彗星组合。 长轮询是真的很好你的带宽，也是真正有用的MB用户。因为当用户发送请求用户将支付它像MB或某种互联网连接。例如对于短期轮询，当你做一些像发送请求每第二用户的互联网使用将更多，因为每个连接用户将支付（这意味着用户松动Mb），但在长期投票用户只会支付新的消息。
Websocket真的很好，但是当你使用它的时候，你应该考虑一个很大的问题，那就是很多人不能使用聊天系统，因为Websocket只是用于浏览器的新版本
