我编写了一个小型 Web 应用程序，它基本上是浏览器中的 JQuery 支持的聊天客户端，为了获取我正在使用 AJAX 请求轮询服务器然后附加任何新回复的帖子，我担心让它变得高效在不失去实时感觉的情况下尽可能。
http://darklightweb.co.uk/RealTime/
我看不到任何可能发生中断的方式，因此我每 5 秒轮询一次页面，如果没有可用的新帖子以保持数据传输处于空闲状态，则该页面不返回任何内容，如果它确实有消息，则在顶部消息queue 被发送出去，我会在 Ajax 请求完成后再次检查，直到消息队列为空。
关于使其尽可能低带宽或可能的替代实现的任何其他提示？
轮询可能不是实现聊天的最佳解决方案 - 我建议看一下JQuery 的 COMET 实现，它保持与客户端的开放连接并从服务器“关闭”推送更新，并且还具有相当的可扩展性。
我认为您可以使用聊天应用程序
反向 Ajax 是一种 Ajax 设计模式，它使用长寿命 HTTP 连接来实现 Web 服务器和浏览器之间的低延迟通信。基本上，它是一种从客户端向服务器发送数据的方式，也是一种将服务器数据推送回浏览器的机制。1
这种服务器-客户端通信采用以下两种形式之一：
* Client polling, the client repetitively queries (polls) the服务器并等待答复。* 服务器推送，服务器和客户端之间的连接保持打开，服务器在可用时发送数据。
反向 Ajax 描述了这些模型中的任何一个或两者的组合的实现。该设计模式也称为 Ajax Push、Full Duplex Ajax 和 Streaming Ajax。
和
Request.Comet 是一个简单的 javascript 类，可以轻松创建跨浏览器 Comet(Reverse Ajax) 应用程序。它提供客户端和服务器之间的实时数据传输，并且可以与任何服务器端语言一起使用。
当各种雇主使用严格的网络过滤时，我编写了几乎完全相同的应用程序来促进工作中的朋友之间的交流。
我发现为这些轮询请求传输的数据量很少，每个登录用户很少接近 1kb/s，通常更少，因为您只轮询 5 秒。
带宽真的是一个问题还是你过早地优化？
If you decide not to go with the COMET approach, then I would do the same as you do, except if the queue contains several messages then they are sent all at once. This way you only poll exactly every 5 seconds and no more (and no less). Of course, with 100 people connected this still results in 20 requests per second, so you should try and optimize the server side in such a way that each request takes as little server resources (CPU/RAM/time) as possible. Caching is your friend here.
I wouldn't worry about bandwidth though because chat messages are usually very short and your requests would be tiny anyway.
为了配合 msparer 的回复，这里有一篇关于 Comet 消息率和对聊天应用程序的这种技术进行基准测试的博客文章：
http://cometdaily.com/2008/10/30/comet-apps-will-not-scale-equally/