如何写一个高效的php聊天程序？
我在用户端 pullstyle 上使用 JQUERY 编写了一个 PHP 聊天脚本。它每秒重新加载一次 pull.php 页面，并从我的 sql 数据库中检索自上次检查以来的新聊天记录。
然而，我收到了主机发来的一封电子邮件，说我使用了太多带宽。布莱赫。我的聊天正如我所愿，而这一切就发生了。我害怕进行 COMET php 聊天，因为我被告知它为每个用户使用单独的进程或线程。
我想我只需要一个比我现有的更好、更有效的策略。
I wrote a PHP chatscript with JQUERY on the userend pullstyle. It reloaded a pull.php page once a second and retrieved only new chat records from my sql database since the last check.
However I got an email from my host saying I was using too much bandwidth. Bleh. My chat was working just as I wanted it and this happened. I'm scared to do a COMET php chat because I was told it uses a separate process or thread foreach user.
I suppose I just need a strategy that's good, and more efficient than what I had.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
好吧，你已经把前提搞定了。 1 秒的召回太频繁了——有人能在一秒钟内做出回应并期望它能够通过吗？我至少需要 2 秒钟才能将我的 SO 消息组合在一起/相对没有拼写错误。
所以第 1 部分 - 增加回忆时间。如果将时间延长到 10 秒，应用程序仍然会感觉相当快，但处理速度却减少了 10 倍 - 这是巨大的。请记住，每条消息都包含额外的数据（在 HTML 中以及支持它的所有网络层中），并且服务器收到的每条消息都需要进行处理以决定如何处理它。
第 2 部分 - 您可能想要引入交互速度的滑动比例。当用户一段时间没有打字并且没有收到消息时，重新检查率可能会降低到 30 秒。如果用户在一次“拉取”中收到多条消息，或者在最近 3 次连续拉取中收到一条消息，则速度应该增加（甚至可能比 10 秒更频繁）。这会让用户在对话期间感觉很快，而在没有任何事情发生时不会缓慢/滞后。
第 3 部分 - 听起来您已经在这样做了，但您的拉动应该提供尽可能少的回复。这只是用于呈现新消息的 HTML 片段，甚至可能只是可以由客户端 JavaScript 呈现的 JSON 结构。如果您再次收到所有消息（不好）或再次收到整个页面（更糟糕），您可以通过这种方式严重减少带宽。
第 4 部分 - 您可能想要查看替代服务器软件。 Apache 有一些严重的开销......这是有充分理由的，你已经运行了所有插件，apache 配置，.htaccess 配置，重写，厨房水槽 - 你也许可以切换到更轻量级的 http 服务器 - nginx 、 lighttp - 并实现一些严重的性能提升（严格来说，它对带宽没有太大帮助 - 但有人想知道这是否是主机真正抱怨的，或者您的服务消耗了大量的服务器资源）。
第 5 部分 - 您可以考虑切换主机或软件包 - 我确信这是一个可怕的想法，但可能有更多带宽/处理器的软件包（我怀疑后者更关键）可用......您甚至可以移动到您的自己的服务器，让您可以做您想做的事情，而无需服务提供商参与。
Well you've got the premise down. 1 second recalls are far too frequent - can anyone bang out a response in a second and expect it to go through? It takes me at least 2 seconds to get my SO messages together / relatively typo free.
So part 1 - increase the recall time. You kick it up to 10 seconds, the app is still going to feel pretty speedy, but you're decreasing processing by a factor of 10 - that's huge. Remember every message includes extra data (in the HTML and in all the network layers that support it), and every received message by the server requires processing to decide what to do with it.
Part 2 - You might want to introduce a sliding scale of interactivity speed. When the user isn't typing and hasn't received a message in a while the recheck rate could be decreased to perhaps 30 seconds. If the user is receiving more than one message in a "pull" or has received a message for the last 3 consecutive pulls then the speed should increase (perhaps even more frequent than 10 seconds). This will feel speedy to users during conversations, and not slow/laggy when there's nothing going on.
Part 3 - Sounds like you're already doing it, but your pull should be providing the minimum possible reply. That is just the HTML fragment to render the new messages, or perhaps even just a JSON structure that can be rendered by client-side JavaScript. If you're getting all the messages again (bad) or the whole page again (worse) you can seriously decrease your bandwidth this way.
Part 4 - You may want to look at alternate server software. Apache has some serious overhead... and that's for good reason, you've got all your plugs running, apache config, .htaccess config, rewrites, the kitchen sink - you might be able to switch to a lighter weight http server - nginx, lighttp - and realise some serious performance increase (strictly speaking it won't help much with bandwidth - but one wonders if that's what the host is really complaining about, or that your service consumes serious server resources).
Part 5 - You could look at switching host, or package - a horrible thought I'm sure, but there may be packages with more bandwidth/processor (the later being more key I suspect) available... you could even move to your own server which allows you to do what you want without the service provider getting involved.
您不需要每秒检查一条新消息，只需将其减少到 3 或 4 条即可。确保您仅使用 1 个查询，并且加载的文件尽可能小。我总是会添加一个超时...它会在一两分钟没有活动后停止重新加载。
做出这些改变，看看这会给你带来什么。
如果您想看看我们是否可以提供帮助，请发布一些代码。
You don't need to check for a new message every second, kick it down to maybe 3 or 4. Make sure you are only using 1 query and that the file loaded is as small as possible. And I would always add a timeout... it would stop reloading after a minute or 2 of no activity.
Make these changes and see where that puts you.
Post some code if you want to see if we can help.
我相信彗星是唯一的解决方案。
线程比进程轻得多，因此您需要将 COMET 类型的技术与轻线程 Web 服务器（如 lighthttpd）一起使用。
I believe that comet is the only solution.
Threads are much lighter than processes, so you would want to use a COMET type technology with a light threaded web server like lighthttpd.
看看简单聊天。我认为它非常小并且可扩展。
Take a look at Simple Chat. It's very tiny and extensible i think.
您需要做的就是“继续使用可用的标准解决方案之一”......
Comet、Web Socket、XMPP 是您经常听到的几个词，那么，只需选择其中之一，它应该会更高效比基于 php 聊天的经典定期 ajax 调用。
如果您想继续使用基于 PHP 和 jQuery 的解决方案，请尝试使用 XMPP 的基于浏览器的聊天系统的这两个工作示例： http: //bit.ly/jaxlBoshChat（一对一聊天示例）和 http://bit.ly/jaxlBoshChat（一对一聊天示例） ly/jaxlBoshMUC（用于多用户聊天示例）。如果您在设置它们时遇到任何问题，请告诉我。
All you need to do is "move ahead with one of the standard solutions available"....
Comet, Web Socket, XMPP are a few words you will hear every now n then, just pick one of them and it should be more efficient than classic periodic ajax call based php chat.
If you want to go ahead with PHP and jQuery based solution, try these two working examples of browser based chat system using XMPP: http://bit.ly/jaxlBoshChat (for one-to-one chat example) and http://bit.ly/jaxlBoshMUC (for multi-user chat example). Let me know if you face any problem setting them up.