AJAX / PHP为什么HTTP-Polling如此滞后？

Question

为什么HTTP-Polling如此滞后？

我所拥有的是一个按钮，每当用户点击它时，MySQL数据库字段就会更新，并且该值会显示给用户。我每800毫秒进行一次轮询，这是非常迟钝/毛刺。有时单击按钮时不会注册。而且我实际上需要比每800毫秒更频繁地进行轮询。

这也是网站上一次只有一个用户...最终会有很多人同时出现。

Answer 1

HTTP-streaming / Long-polling / Websockets而不是轮询

当您需要实时信息时，应避免轮询（经常）。下面我会试着解释为什么这是错误的。您可以将它与汽车后部的一个孩子进行比较，每秒钟“我们还在那里”，而您却一直在回答“我们还没有”。

相反，您希望有类似长轮询/ HTTP流或websockets的东西。你可以将它与你车后面的一个孩子进行比较，告诉你当“我们在那里”时让他知道，而不是每秒都问我们。你可以想象这比前面的例子更有效率。

老实说，我认为PHP不是适合此类应用程序的工具。您可以使用的一些选项是：

托管解决方案：

• http://pusherapp.com：

    

  Pusher是一个快速托管的API，   轻松安全地添加可扩展性   通过WebSockets实时实现功能   到网络和移动应用。

  ---

    

  我们的免费沙盒计划包括最多   20个连接和100,000条消息   每天。只需升级到付费计划   当你准备好了。

• http://beaconpush.com/

    

  Beaconpush是一项推送服务   使用创建实时Web应用程序   HTML5 WebSockets和Comet。

托管自己：

• http://socket.io：

    

  Socket.IO旨在制作实时应用   适用于所有浏览器和移动设备   设备，模糊了差异   不同的运输之间   机制

当变得非常大时，“自己主持”解决方案会变得更便宜，但另一方面使用像pusherapp这样的东西会让你开始更容易（友好的API）并且也不那么昂贵。例如，pusherapp的“Bootstrap”每天可以有100个并发连接和200,000条消息，每月19美元（但是当小的beaconpush更便宜=＆gt;做数学:)）。作为附注，此计划不包括SSL，因此不能用于敏感数据。我想拥有一台专用机器（VPS）将花费你相同的金额（对于一个简单的网站），你也必须自己管理流媒体解决方案，但是当变大时，这可能更有吸引力。

---

内存而不是光盘

  

每当用户点击MySQL时   数据库字段得到更新和   值显示给用户

将磁盘I / O（标准模式下的MySQL）与内存进行比较时，速度非常慢。您应该使用内存数据库，例如redis（也有持久快照）或memcached（完全在内存中）来加速进程。我自己真的很喜欢redis，因为它是疯狂的速度，简单和持久的快照。 http://redistogo.com/提供5MB内存的免费计划，可能会满足您的需求。如果不是每个5美元的迷你计划可能会覆盖你，但是当变得更大时，VPS会更便宜，而且在我看来是首选的解决方案。

---

最佳解决方案

最好的解决方案（特别是如果你变大了）是使用VPS（成本金钱）自己托管socket.io/redis。如果真的很小我会使用redistogo，如果不是，我会自己主持。我也会开始使用像beaconpush / pusherapp这样的东西，因为它很简单（立即开始）。托管socket.io（建议在你自己的机器上玩它时变大）很简单，但在我看来比beaconpush / pusherapp更难。

Answer 2

Laggy /出问题？听起来像客户端问题。按钮的东西也是如此。我先点击你的JavaScript。

至于民意调查，0.8听起来有点时间关键。我不知道大多数国家，但在第三世界，简单的网络数据包可能会延迟几秒钟。 （更不用说连接丢失，数据包丢失和光速。）您的应用程序是否已准备好应对所有这些？

至于另一种方法，我同意@Vern，因为中断驱动的会更好。在HTTP术语中，它转换为长期的HTTP请求，在服务器发送一些实际数据之前不会收到响应，从而最大限度地减少延迟和带宽。 （AFAIK）它是一种比AJAX更古老的技术，尽管最近被命名。搜索“COMET”，您将最终得到客户端和服务器端库。

Answer 3

有许多事情可能会导致您遇到的延迟。您的服务器可能能够足够快地处理请求，但如果客户端和服务器之间的连接速度很慢，那么您将看到明显的延迟。

您应该尝试的第一件事是ping服务器并查看您获得的响应时间。

其次，您可能想要考虑中断驱动的方法，而不是轮询。这意味着只有当您的服务器回复时，您才会发送下一个请求。这是有道理的，因此许多客户端不会充斥服务器的请求直到服务器无法应对。尤其如此，您的请求的RTT（往返时间）非常长。

希望它有所帮助。干杯！

Answer 4

一个好的起点是在Mozilla Firefox中使用Firebug之类的工具，它可以让您观察发送到服务器的请求并查找瓶颈。

Firebug会分解请求的每个部分，因此您可以查看您是否在与服务器通信时遇到问题，或者只是花了很长时间才能得出响应。

Answer 5

除了@Vern的答案之外，我还会说，如果可能的话，我会让服务器提前缓存数据，然后所有客户端都会从同一个缓存中拉出来而不需要单独的MySQL调用来达到相同的目的每次更新的数据。然后，只要实际的数据库数据发生变化，您就可以让PHP更新缓存。

通过缓存我的意思是让php写入服务器端的文件，然后客户端只需查看该文件的内容即可查看最新的信息。可能有更好的缓存方式，但由于我以前从未亲自做过这个，这是我脑海中浮现的第一个解决方案。