长轮询与流式传输大约 1 次更新/秒答案

【问题标题】：long polling vs streaming for about 1 update/second长轮询与流式传输大约 1 次更新/秒
【发布时间】：2010-11-07 23:58:10
【问题描述】：

流媒体是一个可行的选择吗？根据我的选择，服务器端是否会有性能差异？在这种情况下，一个比另一个好？

我正在开发一个在服务器端运行 Tomcat 的 GWT 应用程序。为了了解我的需求，想象一下同时更新几只股票的股价。

【问题讨论】：

标签： gwt streaming comet long-polling

【解决方案1】：

这并不重要。 HTTP1.1 的连接重新协商开销非常小，您不会注意到任何显着的性能差异。

长轮询的好处是兼容性和可靠性 - 代理、端口、检测断开连接等没有问题。

“真正的”流式传输的好处可能会降低开销，但如前所述，这种好处远比想象的要少。

就个人而言，我发现精心设计的彗星服务器是大量更新和/或服务器推送的最佳解决方案。

【讨论】：

【解决方案2】：

StreamHub GWT Comet Adapter 专为这种流式股票报价场景而设计。此处示例：GWT Streaming Stock Quotes。它同时更新几只股票的股价。我认为下面的实现是 Comet，它本质上是通过 HTTP 流式传输的。

编辑：它对每个浏览器使用不同的技术。引用网站：

有几种不同的底层用于实现 Comet 的技术包括隐藏的 iFrame， XMLHttpRequest/脚本长轮询，以及 Flash 等嵌入式插件。 HTML 5 WebSockets 的介绍未来的浏览器将提供一个 HTTP 的替代机制流媒体。 StreamHub 使用“最适合” 利用最高性能的方法和可靠的技术为每个浏览器。

【讨论】：

【解决方案3】：

对于实时股票价格，我绝对会保持连接打开，并确保用户在断开连接时发出警报/重新连接。

【讨论】：

【解决方案4】：

流式传输会更快，因为数据仅以一种方式通过线路。使用轮询，延迟至少是两倍。

轮询对网络中断更具弹性，因为它不依赖于保持打开的连接。

我会去投票只是为了稳健。

【讨论】：

我想澄清一下，我的问题是关于长轮询而不是传统轮询。此外，NIO 应该是给定的。
你是对的，NIO打破了每个连接限制的线程，减轻了线程需求。

【解决方案5】：

当然，如果您希望推送数据，如果您的服务器能够处理预期的连续连接数，流式传输似乎会提供更好的性能。但是还有一个您没有解决的问题：您是 Internet 还是 Intranet？据报道，流媒体在代理之间存在一些问题，正如您所期望的那样。因此，对于通用解决方案，长轮询可能会为您提供更好的服务 - 对于您了解网络基础设施的 Intranet，流式传输很可能是一种更简单、性能更好的解决方案。

【讨论】：

【解决方案6】：

您希望流程是客户端驱动的还是服务器驱动的？换句话说，您是希望在新数据可用时立即将其推送给客户端，还是希望客户端在他们认为合适的时候请求新数据，即使这可能不是每秒一次？客户能够留下来等待答案的可能性有多大？即使您希望事件每秒发生一次，从客户端的请求到服务器的返回之间需要多长时间？如果超过一秒，我希望您倾向于将事件推送给客户端，但反过来，我希望轮询可以。如果响应花费的时间比间隔时间长，那么您实际上是在流式传输，因为在客户端收到最后一个事件时已经准备好一个新事件，因此客户端基本上可以不断轮询并始终接收事件 - 在这种情况下，流式传输数据实际上会更轻量级，因为您要从流程中移除连接/协商开销。

我怀疑基于客户端（拉取）订阅的服务器负载会更高，而不是流式配置，因为客户端每次都必须重新协商连接，而不是让连接保持打开状态，但是流模型中的每个打开连接也需要服务器资源。这取决于您的协商过程的积极程度与每个打开的连接需要多少内存/处理之间的权衡。不过，我不是专家，所以可能还有其他因素。

更新：This guy 谈到了长轮询和流式传输之间的权衡，他似乎说对于 HTTP/1.1，连接重新协商过程是微不足道的，所以这不是什么大问题。

【讨论】：

嘿 rwmnau，您提供的链接很有启发性。为了回答您的问题，我想尽快将数据推送给用户。
如果您希望尽快将数据推送给用户，那么我认为选择必须是流式传输，因为这将保持基于推送的连接。使用拉取设置，您正在等待客户询问，但使用推送设置，他们将在您将数据提供给他们后立即获得数据。让我知道你最终选择了什么以及为什么！