AJAX 轮询频率 - 长轮询还是不长轮询？答案

【问题标题】：AJAX Polling Frequency - To long poll or not to long poll?AJAX 轮询频率 - 长轮询还是不长轮询？
【发布时间】：2011-04-20 00:22:09
【问题描述】：

我正在构建需要相对恒定的数据库轮询的网页组件。我可以看到两种不同的方法，我想知道其中一种是否比其他更好，或者我是否缺少第三种选择。

1) 每 1 或 2 秒发送一次 AJAX 请求以检查更新。无论是否有新数据，每个请求都会立即返回。
2) 触发一个 AJAX 请求，该请求在接收到数据或发生超时之前不会返回。在其中任何一个发生时，它都会触发下一个请求。（我觉得这叫长轮询？）

数据库查询的数量将与任何一个相同，但使用 #2 时，从浏览器发出的请求会更少，这可以节省带宽和客户端资源。对于服务器，最好让一个 PHP 请求保持活动状态并在查询之间休眠，还是每隔几秒启动一次，轮询数据库，然后关闭？还是没有区别，我对此压力太大了？

编辑：我想我还应该声明这是一个更大的网络应用程序的聊天小部件。通信中的轻微延迟不会杀死用户，因为聊天是次要功能。

【问题讨论】：

这实际上取决于长轮询的时间以及您连接的客户端数量。如果您有 2 或 3 个，长轮询可能会更好（因为更新将是即时的）。如果你有很多，长轮询将非常昂贵，因为每个连接都需要一个 PHP 进程（因为它是保持它打开的 PHP）。所以在那种情况下，我会使用“智能”轮询间隔。基本上，如果更新的平均时间是 10 秒，则在 5 秒、8 秒、10 秒、11 秒轮询，以此类推）。基本上只是将时间缩短了一半。在服务器上更容易（因为平均负载下降），但速度很快......
我想我还应该声明这是一个更大的网络应用程序的聊天小部件。通信中的轻微延迟不会杀死用户，因为聊天是次要功能。但我们希望它是合理的（在 2 秒内？）
老实说，我不会在 PHP 中这样做。获得另一种语言，并实现一个队列系统并使用持久的 TCP 连接来回交谈......或者，为什么不简单地安装 Jabber 并完成（也许实现一个到服务器的 JS 接口）......
不幸的是，我无法控制基础架构……要么是 PHP，要么什么都没有。此外，由于要安装 Jabber 之类的环境，它也存在一些限制。不过建议很好。

【解决方案1】：

您还可以查看websockets，它是最新浏览器的一部分（或通过您放在页面上的Flash file 进行模拟）

【讨论】：

【解决方案2】：

长轮询将比轮询更好地扩展（即更少的服务器负载），同时提供更好的响应时间。

如果您的收件人进行投票，则消息的平均行程时间将为您的投票间隔的一半。

通过长轮询，它的即时性 - 服务器仅在无话可说时等待。

如果您正在发送聊天消息，请进行长轮询；这是一个可用性问题。

长轮询的缺点是实现起来更复杂；但它并没有那么复杂，并且被广泛实施。因此，如果您不能为您选择的网络服务器使用现成的框架，您可以开始合理地编写一个框架，并且您会得到它的工作。

【讨论】：