Facebook 应用程序速率限制 #4 - 2018 年 6 月错误
Facebook Application Rate Limit #4 - June 2018 Bug
Facebook 似乎遇到了有关其速率限制的错误。
在撰写本文时，该错误已经开放了好几天。
我相信每个人都知道这会严重影响这些开发人员的客户群。
请求限制似乎是零星的，并且与文档不一致。
实际速率限制似乎已大幅增加，与 "normal" 相比只允许一定比例的请求
几个人似乎受到影响：
https://developers.facebook.com/support/bugs/169774397034403/
有没有人有任何解决方法、建议或见解来缓解这个问题？
提交的原始错误报告：
Our application has been encountering the "GraphAPIError: (#4)
Application request limit reached" error on and off for the past
several days. Our application monitors several of our users accounts
and pulls data for every FB Page, and it has for the past few years
made a number of API calls to gather metrics on those accounts which
would normally occur over a period of less than two hours every day.
On May 25th, we were able to make 1% of the API calls we normally make
over a 24 hour period due to the Application rate limit. On May 26th,
we got 3% of the API calls we normally make over a 24 hour period due
to the same Application rate limit. Then for the 27th-29th it went
back to normal, in less than 2 hours we were able to make 100% of the
API calls we normally make, with no errors. Then on the 30th we were
able to make 33% of the normal API calls, and thus far for today the
31st we have been able to make 1% of the normal API calls. Nothing
has changed on our end, and there is no reason why we should only be
able to make 1% of the API calls normally make some days and not for
other days, especially since our application has been doing the same
exact thing for several years now. Any assistance it appreciated.
我的解决方案：
因为我们只访问 page/{page-id} 端点，所以我们计算了每个请求的新帖子数量并延迟了对同一资源的下一个请求。
因此，如果我们查询 API 并从 100 个项目中收到 1 个新项目，我们将显着增加再次调用相同资源 (page-id) 之前的等待时间。
当我们收到接近“满”的响应时，即 90/10，我们会再次稍微增加时间。这样我们就不会在请求“陈旧”数据时浪费请求。
我们还确保只调用我们的“优先页面”，减少竞争请求的项目总数
备注：
- Facebook 控制面板上的 Rate-Limit 小部件未反映
来自 API 的回复：
- 即使仪表板没有反映限制，我们确实收到
通知：
{Application Name} has reached 100% of the hourly rate limit. All API
calls to your app will fail until your app falls below the throttling
limit.
- 根据文档，代码 4 特定于 App Tokens：
https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
- 检查 headers 揭示原因是“total_time”（请求间隔正好 10 秒，直到我们收到 403 响应）：
我的应用程序定期查询我们自己以及竞争对手的几个页面的帖子。 （链接到新闻文章的媒体网站 facebook 页面。我们喜欢将帖子和表现与竞争对手进行比较。）
我为减少问题所做的工作是对竞争对手的帖子使用应用程序令牌，但对我们自己的页面帖子使用页面特定的令牌。这显着减少了对应用程序令牌的调用量，导致速率限制的启动频率大大降低。
我们的应用程序有同样的问题。这是我能够收集到的一些（完全）经验证据。我们的应用程序从某些 public 页面获取数据（帖子和评论）。我们使用 APP 令牌（不是用户令牌）。
速率限制错误#4 似乎总是在我们尝试获取二级评论时发生，即在其他评论下方的评论。当我们试图从评论（甚至是第一级评论）中获得反应时，偶尔会发生这种情况。
同样，这完全是经验证据。但很高兴听到其他人是否可以复制这一发现。
因此我们也遇到了速率限制问题。
我们的解决方案有两个。
第一步，对于始终 运行 速率限制的客户（原因是他们只有一个每日活跃用户但管理着数百个页面），我们正在将用户（员工用户）添加到应用程序.由于我们的应用程序用于安排帖子，因此我们为这些 'new' 用户中的每一个安排了每天出去的帖子。这会增加应用程序的每日活跃用户数量，从而导致 api.
的吞吐量增加
长期解决方案是我们正在构建一个新服务来管理所有 api 调用。它将分析应用程序的吞吐量，根据需要限制 api 调用，并提供有关正在进行的调用和调用的报告洞察 customer/app 以便我们可以更好地优化发出的调用。
只需安装一个 SDK 就可以轻松完成任务，但看起来这行不通了。
这对我有用。如果我将我的脚本限制为每 3650 秒 200 API 次调用，它将 运行 完成。这些数字似乎接近我能做到的最好水平。如果我逐渐增加 API 调用次数或逐渐减少秒数，脚本开始间歇性失败。如果我更改太多，脚本会一直失败。
这可能意味着某些脚本将无法在一天内完成。幸运的是，我的几个小时就完成了。
Facebook 似乎遇到了有关其速率限制的错误。 在撰写本文时，该错误已经开放了好几天。 我相信每个人都知道这会严重影响这些开发人员的客户群。
请求限制似乎是零星的，并且与文档不一致。 实际速率限制似乎已大幅增加，与 "normal" 相比只允许一定比例的请求 几个人似乎受到影响：
https://developers.facebook.com/support/bugs/169774397034403/
有没有人有任何解决方法、建议或见解来缓解这个问题？
提交的原始错误报告：
Our application has been encountering the "GraphAPIError: (#4) Application request limit reached" error on and off for the past several days. Our application monitors several of our users accounts and pulls data for every FB Page, and it has for the past few years made a number of API calls to gather metrics on those accounts which would normally occur over a period of less than two hours every day. On May 25th, we were able to make 1% of the API calls we normally make over a 24 hour period due to the Application rate limit. On May 26th, we got 3% of the API calls we normally make over a 24 hour period due to the same Application rate limit. Then for the 27th-29th it went back to normal, in less than 2 hours we were able to make 100% of the API calls we normally make, with no errors. Then on the 30th we were able to make 33% of the normal API calls, and thus far for today the 31st we have been able to make 1% of the normal API calls. Nothing has changed on our end, and there is no reason why we should only be able to make 1% of the API calls normally make some days and not for other days, especially since our application has been doing the same exact thing for several years now. Any assistance it appreciated.
我的解决方案：
因为我们只访问 page/{page-id} 端点，所以我们计算了每个请求的新帖子数量并延迟了对同一资源的下一个请求。
因此，如果我们查询 API 并从 100 个项目中收到 1 个新项目，我们将显着增加再次调用相同资源 (page-id) 之前的等待时间。
当我们收到接近“满”的响应时，即 90/10，我们会再次稍微增加时间。这样我们就不会在请求“陈旧”数据时浪费请求。
我们还确保只调用我们的“优先页面”，减少竞争请求的项目总数
备注：
- Facebook 控制面板上的 Rate-Limit 小部件未反映 来自 API 的回复：
- 即使仪表板没有反映限制，我们确实收到 通知：
{Application Name} has reached 100% of the hourly rate limit. All API calls to your app will fail until your app falls below the throttling limit.
- 根据文档，代码 4 特定于 App Tokens：
https://developers.facebook.com/docs/graph-api/advanced/rate-limiting
- 检查 headers 揭示原因是“total_time”（请求间隔正好 10 秒，直到我们收到 403 响应）：
我的应用程序定期查询我们自己以及竞争对手的几个页面的帖子。 （链接到新闻文章的媒体网站 facebook 页面。我们喜欢将帖子和表现与竞争对手进行比较。）
我为减少问题所做的工作是对竞争对手的帖子使用应用程序令牌，但对我们自己的页面帖子使用页面特定的令牌。这显着减少了对应用程序令牌的调用量，导致速率限制的启动频率大大降低。
我们的应用程序有同样的问题。这是我能够收集到的一些（完全）经验证据。我们的应用程序从某些 public 页面获取数据（帖子和评论）。我们使用 APP 令牌（不是用户令牌）。
速率限制错误#4 似乎总是在我们尝试获取二级评论时发生，即在其他评论下方的评论。当我们试图从评论（甚至是第一级评论）中获得反应时，偶尔会发生这种情况。
同样，这完全是经验证据。但很高兴听到其他人是否可以复制这一发现。
因此我们也遇到了速率限制问题。
我们的解决方案有两个。
第一步，对于始终 运行 速率限制的客户（原因是他们只有一个每日活跃用户但管理着数百个页面），我们正在将用户（员工用户）添加到应用程序.由于我们的应用程序用于安排帖子，因此我们为这些 'new' 用户中的每一个安排了每天出去的帖子。这会增加应用程序的每日活跃用户数量，从而导致 api.
的吞吐量增加长期解决方案是我们正在构建一个新服务来管理所有 api 调用。它将分析应用程序的吞吐量，根据需要限制 api 调用，并提供有关正在进行的调用和调用的报告洞察 customer/app 以便我们可以更好地优化发出的调用。
只需安装一个 SDK 就可以轻松完成任务，但看起来这行不通了。
这对我有用。如果我将我的脚本限制为每 3650 秒 200 API 次调用，它将 运行 完成。这些数字似乎接近我能做到的最好水平。如果我逐渐增加 API 调用次数或逐渐减少秒数，脚本开始间歇性失败。如果我更改太多，脚本会一直失败。
这可能意味着某些脚本将无法在一天内完成。幸运的是，我的几个小时就完成了。