从众多“活跃”客户端可扩展地轮询AppEngine应用程序？

Question

我正在处理将在Google AppEngine上运行的应用程序。

我打算让该应用程序的Web界面等待来自AppEngine服务器的通知。

理想情况下，我希望使用XMLHttpRequest（）向服务器发出请求，该请求将等待下一个通知来自应用程序。

然而，在AppEngine中似乎没有支持这种类型的逻辑（如果我错了，请纠正我）。这意味着我似乎仅限于定期轮询。

所以问题是：

• 有没有人有一个很好的建议如何最好地设计这种轮询机制，以避免遇到AppEngine的CPU使用配额？需要考虑“活跃”客户端数量的可扩展性。

我特别感兴趣的是建议从客户端妥善管理轮询间隔，以及随着“活跃”客户端数量的增长，有效处理AppEngine应用程序中的请求的提示。

PS ：从服务器轮询的信息类型通常是关于最近更新/添加的信息位的JSON编码信息（最近读取为：过去几秒或几分钟）。 / p>

状态更新

以下是我对此问题的看法摘要：

• 最小化回答轮询方法生成的每个请求所需的CPU负载：使用memcache最小化收集回复信息所需的时间。 需要找到一个很好的例子。
• 为了最大限度地减少“活跃”客户端向服务器生成的请求数量，我有几条线索：
  • 如果用户未在客户端网页中主动交互（即不点击任何内容），则在连续轮询请求到服务器之间的等待时间会逐渐延长。
  • 回顾其他类型的服务器请求，即将轮询请求的结果包含在其他请求结果中以节省请求数。

欢迎使用代码示例的注释和指示！

Answer 1

... OR

您可能对某些pubsub实现感兴趣。就像谷歌和Jaiku的家伙制作的古老pubsubhubbub一样。