Ограничение скорости подачи заявок Facebook # 4 - Июнь 2018 Ошибка

Facebook, похоже, испытывает ошибку в отношении своих ограничений по скорости. Ошибка была открыта в течение нескольких дней на момент написания. Я уверен, что все знают, что это сильно влияет на клиентскую базу этих разработчиков.

Предел запросов кажется спорадическим и не связан с документацией. Фактические лимиты ставок, по-видимому, резко возросли, и только процентная доля запросов по сравнению с "нормальными". По-видимому, пострадали несколько человек:

https://developers.facebook.com/support/bugs/169774397034403/

Есть ли у кого-нибудь какие-либо проблемы, предложения или идеи, чтобы облегчить эту проблему?

Исходный отчет об ошибке представлен:

Наше приложение столкнулось с "пределом запроса приложения GraphAPIError: (№ 4), который в течение последних нескольких дней включал и удалял ошибку. Наше приложение отслеживает некоторые из наших учетных записей пользователей и извлекает данные для каждой страницы FB, и за последние несколько лет он совершил ряд вызовов API для сбора показателей на тех счетах, которые обычно происходят в течение менее двух часов каждый день, 25 мая мы смогли сделать 1% вызовов API, которые мы обычно делаем за 24-часовой период из-за ограничения скорости подачи заявок. 26 мая мы получили 3% вызовов API, которые мы обычно делаем за 24-часовой период из-за того же предела скорости передачи. Затем на 27-29 она вернулась к норме, менее чем за 2 часа мы смогли сделать 100% вызовов API, которые мы обычно делаем, без ошибок. Тогда 30-го мы смогли сделать 33% обычных вызовов API, и до сих пор на сегодняшний день 31-го мы смогли сделать 1% обычных вызовов API. Ничто не изменилось с нашей точки зрения, и нет оснований для того, чтобы мы могли только сделать, чтобы 1% вызовов API обычно делали несколько дней, а не на другие дни, тем более, что наше приложение делало то же самое в течение нескольких лет сейчас. Любая помощь, которую она ценила.

Ответ 1

Таким образом, у нас также возникают проблемы с лимитами ставок.

Наше решение в два раза.

Шаг первый, для клиентов, которые постоянно работают в лимитах ставок (причина в том, что у них только один ежедневный активный пользователь, но управление сотнями страниц) мы добавляем пользователей (пользователей-сотрудников) в приложение. Поскольку приложение предназначено для составления расписаний, у нас есть запланированные посты для каждого из этих "новых" пользователей, чтобы выходить каждый день. Это наносит толчок ежедневному активному номеру пользователей приложений, что приводит к увеличению пропускной способности из api.

Более долгосрочное решение заключается в том, что мы создаем новый сервис для управления всеми вызовами api. Он проанализирует пропускную способность приложений, вызовы дроссельной заслонки по мере необходимости и предоставит отчетность о том, какие вызовы будут сделаны, и каким клиентом/приложением мы можем улучшить оптимизацию вызовов.

Легко просто установить SDK и отправиться в город, но похоже, что этого больше не будет.

Ответ 2

Мое решение:

Поскольку мы обращались только к конечной точке страницы/{page-id}, мы вычислили количество новых сообщений для каждого запроса и задерживали следующий запрос для того же ресурса.

Поэтому, если мы запросили API и получили 1 новый элемент из 100 общих элементов, мы значительно увеличили время ожидания до того, как снова будет вызван тот же ресурс (page-id).

Когда мы получим ответ, который ближе к "полному", т.е. 90/10, мы немного увеличим время снова. Таким образом, мы не тратим запросы на запрос "устаревших" данных.

Мы также удостоверились, что вызываем только "приоритетные страницы", уменьшая общее количество предметов, оспаривающих запросы

Заметки:

Виджет Rate-Limit на панели инструментов Facebook, не отражающий ответы API:

Несмотря на то, что приборная панель не отразила границы, мы получаем уведомления:

{Название приложения} достигло 100% от почасовой ставки. Все вызовы API для вашего приложения провалится, пока ваше приложение не опустится ниже предела дросселирования.

Согласно документации, код 4 относится к App Tokens:

https://developers.facebook.com/docs/graph-api/advanced/rate-limiting

Проверка заголовков показывает, что причиной является "total_time" (запросы были сделаны ровно на расстоянии 10 секунд, пока мы не получили ответ 403):

Ответ 3

Мое приложение регулярно запрашивает сообщения для нескольких наших, а также наших страниц конкурентов. (Страницы веб-сайтов в средствах массовой информации, ссылающиеся на новостные статьи. Нам нравится сравнивать сообщения и производительность с конкурентами.)

Что я сделал, чтобы уменьшить проблему, это использовать токен приложения для записей конкурентов, но использовать токен для конкретных страниц для наших собственных сообщений на странице. Это значительно сократило количество звонков на токен приложения, в результате чего ограничение скорости было намного меньше.

Ответ 4

Наше приложение имеет ту же проблему. Вот некоторые (полностью) эмпирические доказательства, которые я смог собрать. Наше приложение получает данные (сообщения и комментарии) с определенных общедоступных страниц. Мы используем токен APP (не токен пользователя).

Ошибка ограничения скорости # 4 всегда возникает, когда мы пытаемся получить комментарии второго уровня, то есть комментарии под другими комментариями. И иногда случается, когда мы пытаемся получить ответы от комментариев (даже комментарии первого уровня).

Опять же, это полностью эмпирические данные. Но было бы хорошо услышать, смогут ли другие люди повторить эти выводы.

Ответ 5

Это то, что сработало для меня. Если я ограничу свой скрипт 200 вызовами API каждые 3650 секунд, он будет запущен до завершения. Эти цифры, похоже, близки к лучшему, что я могу сделать. Если я постепенно увеличиваю количество вызовов API или постепенно уменьшаю количество секунд, скрипт начинает прерываться с перерывами. Если я их слишком сильно меняю, сценарий не работает последовательно.

Вероятно, это означает, что некоторые скрипты не смогут завершить через день. К счастью, мое завершение через пару часов.