流媒体是一个可行的选择吗？根据我的选择，服务器端是否会有性能差异？在这种情况下，一个比另一个更好吗？
我正在开发一个在服务器端运行 Tomcat 的 GWT 应用程序。为了理解我的需求，想象一下同时更新几只股票的股价。
问问题
6781 次
6 回答
6
您希望流程是客户端驱动的还是服务器驱动的？换句话说，您是希望在新数据可用时立即将其推送给客户端，还是希望客户端在他们认为合适的时候请求新数据，即使这可能不是每秒一次？客户能够留下来等待答案的可能性有多大？即使您希望事件每秒发生一次，从客户端的请求到服务器的返回之间需要多长时间？如果超过一秒，我希望您倾向于将事件推送给客户端，但反过来，我希望轮询可以。如果响应花费的时间比间隔时间长，那么您实际上是在流式传输，因为在客户端收到最后一个事件时已经准备好一个新事件，
我怀疑基于客户端（拉）订阅的服务器负载会更高，而不是流配置，因为客户端每次都必须重新协商连接，而不是让连接保持打开状态，但是每个打开的连接在流模型中也需要服务器资源。这取决于您的协商过程的积极程度与每个打开的连接需要多少内存/处理之间的权衡。不过，我不是专家，所以可能还有其他因素。
更新：这个人谈到了长轮询和流式传输之间的权衡，他似乎说对于 HTTP/1.1，连接重新协商过程是微不足道的，所以这不是什么大问题。
于 2009-07-07T17:34:19.580 回答
4
这并不重要。HTTP1.1 的连接重新协商开销非常小，您不会注意到任何显着的性能差异。
长轮询的好处是兼容性和可靠性——代理、端口、检测断开连接等没有问题。
“真正的”流媒体的好处可能会减少开销，但正如已经提到的，这种好处远比它想象的要少得多。
就个人而言，我发现精心设计的彗星服务器是大量更新和/或服务器推送的最佳解决方案。
于 2010-04-01T03:45:16.540 回答
2
当然，如果您希望推送数据，如果您的服务器可以处理预期的连续连接数量，流式传输似乎会提供更好的性能。但是还有一个您没有解决的问题：您是 Internet 还是 Intranet？据报道，流媒体在代理之间存在一些问题，正如您所期望的那样。因此，对于通用解决方案，长轮询可能会为您提供更好的服务 - 对于您了解网络基础设施的 Intranet，流很可能是一个更简单、性能更好的解决方案。
于 2009-07-10T18:38:40.057 回答
2
StreamHub GWT Comet 适配器专为这种流式股票报价场景而设计。此处的示例：GWT 流媒体股票报价。它同时更新几只股票的股价。我认为下面的实现是 Comet，它本质上是通过 HTTP 流式传输的。
编辑：它为每个浏览器使用不同的技术。引用网站：
有几种不同的底层技术用于实现 Comet，包括 Hidden iFrame、XMLHttpRequest/Script Long Polling 和 Flash 等嵌入式插件。在未来的浏览器中引入 HTML 5 WebSockets 将为 HTTP 流提供一种替代机制。StreamHub 使用“最适合”的方法，为每个浏览器利用性能最高和最可靠的技术。
于 2009-08-13T17:04:34.590 回答
1
流式传输将更快，因为数据仅以一种方式通过线路。使用轮询，延迟至少是两倍。
轮询对网络中断更具弹性，因为它不依赖于保持打开的连接。
我会去投票只是为了稳健性。
于 2009-07-13T18:21:06.447 回答
1
对于实时股票价格，我绝对会保持连接打开，并确保用户在断开连接时发出警报/重新连接。
于 2009-08-05T20:52:05.793 回答