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

Question

正在推出可行的选择吗？ 根据我的选择，服务器端会有性能差异吗？ 对于这种情况，哪一个比另一个好？

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

Answer 1

您希望流程是客户端还是服务器驱动的？换句话说，您是否希望在客户可用时立即将新数据推送到客户端，或者您是否愿意在客户端认为合适的情况下请求新数据，即使这可能不是一次/秒？客户能够坚持等待答案的可能性是多少？即使您希望事件发生一次/秒，从客户端请求和服务器返回之间需要多长时间？如果它超过一秒钟，我希望你倾向于将事件推向客户，虽然相反，我希望民意调查没问题。如果响应花费的时间超过了间隔，那么你实际上就是流式传输，因为在客户端接收到最后一个事件时会有一个新事件准备就绪，因此客户端本质上可以持续轮询并始终接收事件 - 在这种情况下，流式传输因为你要从进程中删除连接/协商开销，所以数据实际上会更轻量级。

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

更新：This guy谈论长轮询和流媒体之间的权衡，他似乎说使用HTTP / 1.1，连接重新协商过程是微不足道的，所以这不是一个很大的问题。

Answer 2

这并不重要。 HTTP1.1的连接重新协商开销非常小，您不会发现任何重大的性能差异。

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

“真正的”流媒体的好处可能会降低开销，但正如已经提到的，这种好处远远超过它的成就。

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

Answer 3

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

Answer 4

StreamHub GWT Comet Adapter的设计完全符合流媒体股票报价的情况。示例：GWT Streaming Stock Quotes。它同时更新了几只股票的股票价格。我认为下面的实现是Comet，它本质上是通过HTTP传输的。

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

  

有几种不同的基础   用于实施Comet的技术   包括隐藏的iFrame，   XMLHttpRequest / Script Long Polling，   和嵌入式插件，如Flash。   HTML 5 WebSockets的引入   在将来的浏览器中将提供一个   HTTP的替代机制   流。 StreamHub使用“最适合”   利用最高效的方法   每个人都有可靠的技术   浏览器。

Answer 5

流式传输速度会更快，因为数据只会单向穿过线路。通过轮询，延迟至少是两次。

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

我只是为了坚固而进行民意调查。

Answer 6

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