我们正在开发一个网站,允许用户向其他用户发送半实时事件。当用户有新事件时,UI将显示一个图标(非常标准的东西)。
我已经读过定期短轮询不像websockets那样扩展,因为它给Web服务器带来了更大的压力。我不太确定为什么会这样呢?
我们正在使用tomcat NIO(每个线程比没有一对一的连接)。据我了解,Tomcat NIO非常擅长使用少量线程处理更长的HTTP连接超时。
因此,如果定期轮询时间小于连接超时,则轮询不应该创建另一个TCP握手,因为它只会重用现有的HTTP 1.1连接。
因此,上述情况似乎不会对服务器造成太大压力。它可能不像长轮询或websockets一样实时,但我不明白为什么它不应该扩展(假设服务器可以快速响应指示新事件的响应 - 我们使用内存并发hashmap,所以这应该非常快,没有必要的DB访问权限。)
我错过了什么吗?
谢谢, - 亚当
答案 0 :(得分:4)
短轮询可能不像长轮询和网络套接字一样流行,但它可以在任何地方运行和工作。
Trello(由一些与SO相同的人支持)通常使用网络套接字但是当他们在发布日的网络套接字实施中遇到严重错误时,他们通过短轮询保存:
我们在发布后立即遇到问题。我们的WebSocket服务器实现在TechCrunch中断的突然和繁重的实际使用情况下开始表现得非常奇怪,我们很高兴能够通过调整活动和空闲轮询间隔来恢复到普通轮询和调整服务器性能。它让我们优雅地降级,因为我们在一周内从300增加到50,000用户。我们现在回到了WebSockets,但是有一个有效的短轮询系统似乎仍然是一个非常谨慎的后备。
完整story非常值得一读。
我特别强调,
在巴西,至少有许多零售交易平台使用短轮询,轮询间隔非常短,可快速公布股票价格,并定期支持数千名并发用户。
与长轮询和Web套接字不同,短轮询不需要持久连接,因此在中间使用HAProxy之类的最大数量的“连接”实际上可能大于硬件支持的并发套接字数量(尽管那时你可能会看到响应能力有所下降。)