处理新的频道创建限制
Google 应用引擎最近似乎将频道创建的免费配额从每天 8640 个大幅减少到 100 个。对于我不愿意使用付费计划的业余爱好项目，我希望得到一些优化频道创建的建议。
文档中特别提到了这一点 每个通道 ID 只能有一个客户端。如果有办法解决这个问题，即使它仅适用于一台计算机上的多个客户端（例如多个选项卡），也会有所帮助
我突然想到，我也许可以通过向客户端重复发送 XHR 请求来模拟通道功能。服务器检查新消息，从而绕过限制。但是，我担心这种方法可能太慢。是否有任何现有的库遵循这一原则？
Google app engine seems to have recently made a huge decrease in free quotas for channel creation from 8640 to 100 per day. I would appreciate some suggestions for optimizing channel creation, for a hobby project where I am unwilling to use the paid plans.
It is specifically mentioned in the docs that there can be only one client per channel ID. It would help if there were a way around this, even if it were only for multiple clients on one computer (such as multiple tabs)
It occurred to me I might be able to simulate channel functionality by repeatedly sending XHR requests to the server to check for new messages, therefore bypassing limits. However, I fear this method might be too slow. Are there any existing libraries that work on this principle?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个通道一个客户端
不幸的是，没有一种简单的方法可以解决每个通道 ID 一个客户端的限制。我们实际上允许两个，但这是为了处理用户刷新页面的情况，而不是为了实际的扇出。
也就是说，您当然可以为此实施自己的解决方法。我见过的一种技巧是使用 cookie 在浏览器选项卡之间进行通信。然后，您可以选择一个选项卡作为频道的“所有者”，并通过 cookie 扇出数据。有关如何实现选项卡间通信的信息，请参阅此问题： 浏览器选项卡之间的 Javascript 通信/windows
轮询与通道
如果您愿意接受一些性能权衡，则可以使用轮询而不是使用通道 API。通道API传输速度在100-200ms左右；如果你可以接受平均 500 毫秒，那么你可以每秒轮询一次。根据您发送的数据类型以及内存缓存中可以容纳的数据量，这可能是一个可行的解决方案。我的猜测是你最大的问题将是实例时间。
例如，如果您有 100 个客户端，您将看到 100qps。您应该进行试验，看看是否可以在一秒钟内为您需要提供的数据提供 100 个请求，而无需启动第二个实例。如果没有，请继续增加延迟（即降低轮询频率），直到有 1 个实例能够满足您的请求。
希望有帮助。
One Client per Channel
There's not an easy way around the one client per channel ID limitation, unfortunately. We actually allow two, but this is to handle the case where a user refreshes his page, not for actual fan-out.
That said, you could certainly implement your own workaround for this. One trick I've seen is to use cookies to communicate between browser tabs. Then you can elect one tab the "owner" of the channel and fan out data via cookies. See this question for info on how to implement the inter-tab communication: Javascript communication between browser tabs/windows
Polling vs. Channel
You could poll instead of using the Channel API if you're willing to accept some performance trade-offs. Channel API deliver speed is on the order of 100-200ms; if you could accept 500ms average then you could poll every second. Depending on the type of data you're sending, and how much you can fit in memcache, this might be a workable solution. My guess is your biggest problem is going to be instance-hours.
For example, if you have, say, 100 clients you'll be looking at 100qps. You should experiment and see if you can serve 100 requests in a second for the data you need to serve without spinning up a second instance. If not, keep increasing your latency (ie., decreasing your polling frequency) until you get to 1 instance able to serve your requests.
Hope that helps.