定期短轮询是否在服务器上扩展？

Question

我们正在开发一个站点，允许用户向其他用户发送半实时事件。当用户有新事件时，UI 将显示一个图标（非常标准的东西）。

我读过定期短轮询的扩展性不如 websockets，因为它给 web 服务器带来了更大的压力。我不太确定为什么会这样？

我们正在使用 tomcat NIO（每个线程比率没有一对一的连接）。据我了解，Tomcat NIO 非常擅长使用少量线程处理较长的 HTTP 连接超时。

因此，如果定期轮询时间小于连接超时，则轮询不应创建另一个 TCP 握手，因为它只会重用现有的 HTTP 1.1 连接。

因此，上述内容似乎不会对服务器造成太大压力。它可能不像长轮询或 websockets 那样实时，但我不明白为什么它不应该扩展（假设服务器可以快速响应指示新事件的响应——我们使用内存中的并发哈希图，所以这应该很快，没有必要的数据库访问）。

我错过了什么吗？

谢谢，-亚当

Answer 1

短轮询可能不像长轮询和网络套接字那样流行，但它在任何地方都有效。

Trello（由一些与 SO 相同的人支持）通常使用网络套接字，但是当他们在发布当天在他们的网络套接字实现中遇到一个严重的错误时，他们通过短轮询得以保存：

我们在发布后立即遇到了问题。我们的 WebSocket 服务器实现在 TechCrunch 中断的突然和大量实际使用中开始表现得非常奇怪，我们很高兴能够通过调整活动和空闲轮询间隔恢复到普通轮询和调整服务器性能。随着我们在一周内从 300 名用户增加到 50,000 名，它使我们能够优雅地降级。我们现在又回到了 WebSockets 上，但是拥有一个有效的短轮询系统似乎仍然是一个非常谨慎的后备。

完整的故事非常值得一读。

我要特别强调，

1. 使用 HAProxy 来终止客户端连接。这意味着内部 Web 服务器不受缓慢和行为不端的客户端的影响，并且由于 HAProxy 的可扩展性/效率，重复创建连接的开销变得不那么重要；
2. Trello 的轮询频率是可调的，这意味着在重负载下，他们可以告诉所有客户端降低轮询频率，从而交换响应能力以增加容量。

至少在巴西有很多零售交易平台使用短轮询，轮询间隔非常短，可以快速发布股票价格，并定期支持数千个并发用户。

与长轮询和 Web 套接字不同，短轮询不需要持久连接，因此在中间使用 HAProxy 之类的东西时，您的最大“连接”数实际上可能大于硬件支持的并发套接字数（尽管那时您可能会看到响应能力有所下降）。