在像Trello.com这样的网站上，我注意到在firebug控制台中，它会频繁地定期向其服务器发出Ajax POST调用，以便从数据库中检索新数据，并在新内容可用时更新dom。
另一方面，Facebook通知似乎正在实施COMET推送机制。
每种方法的优点和缺点是什么，具体来说，我的问题是为什么Trello.com使用“拉”机制，因为我一直认为使用这种方法（特别是因为它如此频繁地ping服务器）看起来像它不是一个可扩展的解决方案 - 当越来越多的用户注册使用其服务时？
答案 0 :(得分：5)
你的直觉是正确的。长轮询（aka comet）将比直接轮询更有效。并且当可用时，websockets将比长轮询更有效。那么为什么一些公司使用“拉动轮询”很简单：它们已经过时了，需要花些时间来更新它们的代码库！
使用传统轮询，您将重复发出相同的请求，通常将响应解析为JSON或将结果作为内容填充到DOM容器中。此轮询的频率与数据更新的频率无关。例如，您可以选择每3秒轮询一次新数据，但是数据可能一次保持30秒不变？在这种情况下，您浪费HTTP请求，带宽和服务器资源来处理许多完全无用的HTTP请求（在任何实际更改之前，相同数据的9次重复）。
通过长轮询（又称彗星），我们可以显着减少浪费。当您的请求发出更新的数据时，服务器会接受请求，但如果没有新的更改则不响应，而是将请求保持打开10秒，20秒，30秒或60秒或直到某些新数据准备就绪它可以回应。最终请求将超时或服务器将响应更新。这里的想法是你不会像上面的3秒轮询那样经常重复相同的数据，但你仍然可以非常快速地获得新数据的通知，因为可能已经有一个打开的请求只是等待服务器响应
你会发现长时间的民意调查可以大大减少浪费，但仍然有可能造成一些浪费。 30-60秒是长轮询的常见超时时间段，因为许多路由器和网关无论如何都将关闭超过该时间的挂起连接。那么，如果您的数据每15分钟实际更改一次怎么办？每3秒轮询一次非常低效，但是在60秒超时的长轮询仍会有一些浪费的往返服务器。
Websockets是下一项技术进步，它允许浏览器打开与服务器的连接，并在需要时保持打开状态，并通过相同的开放websocket传送多个消息或数据块。然后，服务器可以准确地在新数据准备好时发送更新。 websocket连接已经建立并等待数据，因此它快速有效。
问题是Websockets还处于起步阶段。只有最新一代的浏览器支持它，如果有的话。该规范尚未完全批准，因此实施可能因浏览器而异。当然，您的访问者可能正在使用几年前的浏览器。因此，除非您可以控制访问者使用的浏览器（例如企业内部网，IT可以指示工作站上的软件），您将需要一种机制来抽象出这个传输层，以便您的代码可以使用该特定的最佳技术访客的浏览器。
拥有抽象的通信层还有其他好处。例如，如果你的页面上有3个网格控件，那么每隔3秒就会进行一次拉动轮询，看看这会是一团糟吗？现在滚动你自己的长轮询实现可以清除一些，但如果你将所有这三个表的更新聚合成一个长轮询请求，它会更酷。这将再次减少浪费。如果你有一个小项目，你可以再推出自己的项目，但有一个标准的Bayeux Protocol，许多服务器推送实现都遵循。 Bayeux协议自动聚合消息以进行传递，然后通过“频道”（您作为开发人员用于指导消息的任意路径类型字符串）将消息隔离出去。客户端可以在频道上收听，您可以在频道上发布数据，这些消息将通过您发布的频道收听。
随着Push技术成为下一个重要的事情，现在可用的服务器端服务器推送工具包的数量正在快速增长。服务器推出可能有20个或更多工作实现。你自己搜索“{你最喜欢的平台}彗星实现”，因为它会每隔几个月继续改变我确定（并且之前已经覆盖了stackoverflow）。