查询优化和 API 限制答案

【问题标题】：Query optimization and API throttling查询优化和 API 限制
【发布时间】：2012-12-05 15:26:18
【问题描述】：

我们正在跟踪一些客户的 Facebook 页面和帖子指标，我们对高 CPU 强度和过多的帖子/cmets 调用有一些疑问 - 根据开发人员洞察控制台 (Insights ->开发人员-> 活动和错误）。文档对 Graph API 的限制和限制有些不清楚，我们只是想确保我们对可用的资源有正确的理解。

我们正在努力优化我们的软件和查询，以降低错误率和请求数量。关于这项工作，我们有几个问题：

我们已更改为使用 FQL 查询而不是常规的 Graph API 请求来获取 Post cmets，这使我们能够为每个请求获取多个帖子的 cmets。这导致请求数量显着减少。我们使用 page_id IN (PAGE_ID_1, PAGE_ID_2, ....) 的查询。与常规 Graph API 请求相比，这会增加 CPU 强度吗？
我们还对我们的请求实施了限制，以确保我们在一段时间内均匀地分配我们的请求，而不是大量爆发。对于 Page cmets，我们确保 10 分钟内的最大请求数不超过 300。换句话说，我们将主页评论请求的数量限制为每秒 0.5 次或每分钟 30 次。这还高吗？
一旦超过请求限制，我们假设这是访问令牌，而不是 APP ID？因此，如果我们的一个客户过度使用资源，我们的 APP 仍会继续代表我们其他拥有不同访问令牌的客户工作吗？
在开发者控制台中，在我们的应用程序的 Insights -> Developer -> Activity & Errors 页面下，API Throttling 表在其上方有一个时间。例如 1 小时 14 分钟。这个时间表示什么，这个表多久更新一次，数字是多久的？
我们收到少量响应代码为 500 的错误。这些错误是否通常是超出请求和/或 CPU 限制的结果？如果没有，是否有任何方法可以确定真正导致它们的原因，以及我们是否可以采取一些措施来解决它？

我们将不胜感激任何对我们假设的意见和确认。

【问题讨论】：

【解决方案1】：

您的问题的一些答案：

Facebook 对图形 API 请求的限制是每 600 秒 600 个请求...但是批处理请求被计为批处理中每个请求一个请求...我认为 FQL 限制是相同的...
此限制适用于一个 IP 和一个访问令牌，如果您有多个令牌和/或 IP，您可以调整此限制
实际上我没有示例，但是当您打破速度限制时，错误消息类似于“请求过多”，而不是错误 500...不知道在您的情况下可能导致这种情况的原因

一些我不明白的问题： - 当您谈到“CPU 强度”时，您是指在您这边还是 FB 那边？在 FB 方面我从未见过这样的限制，唯一的一个是 600 req / 600 sec...

【讨论】：

如果您在developers.facebook.com/apps 下查看“应用程序”>“您的应用程序”>“见解”>“活动和错误”，如果您将界限推到太多，您将收到 API 限制错误和警告。到目前为止，我看到的 3 种类型是：'Too Many Calls'、'Calls Are Too CPU Intensive'和'Calls Access Too Much Data'。
我也有这样的消息，但在我的例子中，只有“警告”没有错误（此时）......在我们的例子中，我们有一个“速度调节器”锁定在 300 个请求/600 秒，所以也许这就是为什么我们没有诸如错误之类的消息，而只是警告？
显然，APP Token 的 CPU 密集型正在发生。如果可以的话，尽量用Page Token或者User Token来传播爱吧：）
600 个请求/600 秒不是每个令牌和每个 IP 地址。如果您超过此窗口速率限制，您将无法使用相同令牌从不同 IP 地址发出更多请求（我已经对此进行了测试）。