Facebookアプリケーションのレート制限＃4-2018年6月のバグ
Facebookのレート制限に関してバグが発生しているようです。執筆時点では、バグは数日間オープンしています。これはこれらの開発者のクライアントベースに深刻な影響を与えることを誰もが知っていると思います。
リクエストの制限は散発的で、ドキュメントと一致していません。実際のレート制限は大幅に増加しているようで、「通常」と比較してリクエストのパーセンテージしか許可されていません。いくつかの人々が影響を受けているようです：
https://developers.facebook.com/support/bugs/169774397034403/
この問題を軽減するための回避策、提案、または洞察はありますか？
提出された元のバグレポート：
このアプリケーションでは、過去数日間、「GraphAPIError：（＃4）アプリケーションリクエストの制限に達しました」というエラーがオンとオフを繰り返してきました。私たちのアプリケーションは、いくつかのユーザーアカウントを監視し、すべてのFBページのデータをプルします。過去数年間、これらのアカウントに関するメトリックを収集するために、毎日2時間未満の期間で発生する多くのAPI呼び出しを行ってきました。 5月25日、アプリケーションのレート制限により、通常24時間で行うAPI呼び出しの1％を行うことができました。 5月26日に、同じアプリケーションレート制限により、通常24時間で行うAPI呼び出しの3％を受け取りました。その後、27日から29日までは通常に戻り、2時間未満で、通常のAPI呼び出しを100％実行でき、エラーは発生しませんでした。その後、30日には通常のAPI呼び出しの33％を行うことができましたが、今日までのところ、31日までに通常のAPI呼び出しの1％を行うことができました。私たちの側で何も変更されていません。特に、アプリケーションが数年間同じ正確なことを行っているので、API呼び出しの1％だけが通常は数日であり、他の日はできないはずである理由はありません。今。それは感謝しました。
したがって、レート制限の問題もあります。
私たちのソリューションは2つあります。
最初に、レート制限に常に直面しているクライアント（理由は、アクティブなユーザーが1日1人しかいないが数百のページを管理しているため）のために、ユーザー（従業員ユーザー）をアプリに追加します。外出アプリは投稿のスケジュールを設定するためのものなので、これらの「新しい」ユーザーのそれぞれに投稿を毎日外出するようにスケジュールしました。これにより、アプリの毎日のアクティブユーザー数が増加し、APIのスループットが向上します。
長期的な解決策は、すべてのAPI呼び出しを管理する新しいサービスを構築していることです。アプリのスループットを分析し、必要に応じてapi呼び出しを抑制し、行われている呼び出しと、どの顧客/アプリが行ったかについてのレポート洞察を提供するので、発信される呼び出しをより適切に最適化できます。
SDKをインストールして街に出かけるのは簡単ですが、それだけではもうそれがなくなるわけではないようです。
私の解決策：
page/{page-id} エンドポイントにのみアクセスしていたため、リクエストごとの新しい投稿の数を計算し、同じリソースに対する次のリクエストを遅らせました。
したがって、APIをクエリして、合計100のアイテムから1つの新しいアイテムを受け取った場合、同じリソース（ページID）が再度呼び出されるまでの待機時間を大幅に増やします。
「完全」に近い応答、つまり90/10を受け取った場合は、時間を少し増やします。このようにして、「古い」データをリクエストする際にリクエストを無駄にすることはありません。
また、「優先ページ」のみを呼び出すようにして、リクエストに対して競合するアイテムの総数を減らしました。
ノート：
- APIからの応答を反映していないFacebookダッシュボードのレート制限ウィジェット：
- ダッシュボードには制限が反映されていませんが、通知を受け取ります。
{アプリケーション名}は1時間あたりのレート制限の100％に達しました。アプリがスロットル制限を下回るまで、アプリへのすべてのAPI呼び出しは失敗します。
- ドキュメントによると、コード4はアプリトークンに固有です。
https://developers.facebook.com/docs/graph-api/advanced/rate-limited
- ヘッダーを調べると、原因が「total_time」であることがわかります（403応答を受信するまで、リクエストは正確に10秒間隔で行われました）。
私のアプリケーションは、自分のページと競合他社のページのいくつかの投稿を定期的に照会します。 （ニュース記事にリンクするメディアWebサイトのFacebookページ。投稿とパフォーマンスを競合他社と比較したい。）
この問題を軽減するために私が行ったのは、競合他社の投稿にはアプリトークンを使用し、独自のページ投稿にはページ固有のトークンを使用することです。これにより、アプリトークンの呼び出し量が大幅に減少し、レート制限が発生する頻度が大幅に減少しました。
これは私のために働いたものです。スクリプトを3650秒ごとに200回のAPI呼び出しに制限すると、スクリプトは最後まで実行されます。これらの数値は、私が実行できる最善の方法に近いようです。 API呼び出しの数を徐々に増やしたり、秒数を徐々に減らしたりすると、スクリプトが断続的に失敗し始めます。変更しすぎると、スクリプトが常に失敗します。
これはおそらく、一部のスクリプトが1日で完了できないことを意味します。幸い、鉱山は数時間で完了します。
アプリケーションにも同じ問題があります。ここに私が集めることができた（完全に）いくつかの経験的証拠があります。アプリケーションは、特定のパブリックページからデータ（投稿とコメント）を取得します。 APPトークンを使用します（ユーザートークンではありません）。
2番目のレベルのコメント、つまり他のコメントの下にあるコメントを取得しようとすると、レート制限エラー＃4が常に発生するようです。そして、時々、コメントからの反応を得ようとするときに発生します（第1レベルのコメントでさえ）。
繰り返しますが、これは完全に実証的な証拠です。しかし、他の人がこの調査結果を再現できるかどうか聞いていただければ幸いです。