Наша цель — всегда доставлять каждое сообщение, отправленное через FCM. Однако доставка каждого сообщения иногда приводит к ухудшению общего пользовательского опыта. В других случаях нам необходимо установить ограничения, чтобы FCM предоставлял масштабируемый сервис для всех отправителей. Типы ограничений и квот, описанные в этом разделе, помогают нам сбалансировать эти важные факторы.
Регулирование нисходящих сообщений
В API HTTP v1 введены поминутные квоты на отправку сообщений по каждому проекту. Квота по умолчанию в 600 тыс. сообщений в минуту охватывает более 99% разработчиков FCM , обеспечивая при этом стабильность системы и минимизируя влияние нестабильных проектов.
Резкие колебания трафика могут привести к ошибкам превышения квоты. В случае превышения квоты система возвращает код статуса HTTP 429 RESOURCE_EXHAUSTED ("QUOTA_EXCEEDED") до тех пор, пока квота не будет заполнена в течение следующей минуты. Ответы 429 также могут возвращаться в ситуациях перегрузки, поэтому настоятельно рекомендуется обрабатывать ошибки 429 в соответствии с опубликованными рекомендациями .
Иметь в виду:
- Квота нисходящего потока измеряет сообщения, а не запросы.
- Ошибки клиента (коды статуса HTTP 400-499) подсчитываются (исключая 429).
- Квоты поминутные, но эти минуты не привязаны к часам.
Квота мониторинга
Вы можете просмотреть квоту, использование и ошибки в Google Cloud Console, используя следующее:
- Перейдите в консоль Google Cloud .
- Выберите API и сервисы .
- В списке таблиц выберите Firebase Cloud Messaging API .
- Выберите КВОТА И СИСТЕМНЫЕ ОГРАНИЧЕНИЯ .
Запросить увеличение квоты
Прежде чем подавать запрос на увеличение квоты, убедитесь, что:
- Ваше использование регулярно составляет ≥ 80% от квоты в течение не менее 5 последовательных минут в день.
- Коэффициент ошибок клиентов составляет < 5%, особенно в периоды пиковой нагрузки.
- Вы придерживаетесь лучших практик широкомасштабной рассылки сообщений .
Если вы соответствуете этим критериям, вы можете подать запрос на увеличение квоты до +25%, и FCM приложит все возможные усилия для выполнения запроса (увеличение квоты не может быть гарантировано).
Если вам требуется дополнительная квота на отправку сообщений в нисходящем направлении в связи с предстоящим запуском или временным событием, запросите квоту не менее чем за 15 дней, чтобы у вас было достаточно времени для обработки запроса. Для больших запросов (>18 млн сообщений в минуту) требуется уведомление не менее чем за 30 дней. Запуски и запросы на специальные события по-прежнему подчиняются требованиям к уровню ошибок клиента и передовым практикам.
Более подробную информацию см. в разделе Квоты FCM .
Ограничения на количество сообщений в теме и регулирование количества ответвлений
Более подробную информацию см. в разделе Квоты и ограничения на отправку сообщений в темах .
Сворачиваемое ограничение сообщений
Как описано в разделе «Сворачиваемые сообщения» , сворачиваемые сообщения — это уведомления без содержания, которые сворачиваются друг на друга. Если разработчик слишком часто отправляет одно и то же сообщение приложению, мы откладываем отправку сообщений, чтобы снизить нагрузку на аккумулятор пользователя.
Например, если вы отправляете большое количество новых запросов на синхронизацию электронной почты на одно устройство, мы можем отложить следующий запрос на синхронизацию на несколько минут, чтобы устройство могло синхронизироваться с более низкой средней скоростью. Такое ограничение применяется исключительно для минимизации воздействия на аккумулятор пользователя.
Если ваш сценарий использования требует частой отправки, то неразворачиваемые сообщения могут быть правильным выбором. В таких сообщениях обязательно включайте контент, чтобы снизить расход заряда батареи.
Мы ограничиваем сворачиваемые сообщения пакетом в 20 сообщений на приложение на одно устройство с пополнением на 1 сообщение каждые 3 минуты.
Максимальная скорость отправки сообщений на одно устройство
На Android можно отправлять до 240 сообщений в минуту и до 5000 сообщений в час на одно устройство. Этот высокий порог предназначен для кратковременных всплесков трафика, например, при быстром общении пользователей в чате. Это ограничение предотвращает непреднамеренную разрядку аккумулятора устройства из-за ошибок в логике отправки.
Для iOS мы возвращаем ошибку, если скорость превышает ограничения APN.