Лимиты на использование

Поскольку API Google Workspace Events является общим сервисом, мы применяем квоты и ограничения, чтобы обеспечить его справедливое использование всеми пользователями и защитить общую производительность Google Workspace.

Если вы превысите квоту, вы получите ответ с кодом состояния HTTP 429: Too many requests . Дополнительные проверки ограничения скорости на серверной части API Google Workspace Events также могут привести к такому же ответу об ошибке. Если возникает эта ошибка, вам следует использовать алгоритм экспоненциальной отсрочки и повторить попытку позже. Пока вы соблюдаете поминутные квоты, указанные в следующих таблицах, количество запросов, которые вы можете делать в день, не ограничено.

Квоты на проект

Квоты для каждого проекта ограничивают частоту запросов для проекта Google Cloud и, таким образом, применяются к одному приложению, вызывающему указанные методы API событий Google Workspace для каждой квоты.

В следующей таблице подробно описаны ограничения запросов для каждого проекта. Вы также можете найти эти ограничения на странице «Квоты» в консоли Google Cloud.

Квота на проект

Методы API событий Google Workspace

Лимит

Пишет в минуту

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

Записей в минуту на пользователя

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

Чтений в минуту

Subscriptions.get

Subscriptions.list

600

Чтений в минуту на пользователя

Subscriptions.get

Subscriptions.list

100

Устранение ошибок квот на основе времени

Для всех ошибок, связанных со временем (максимум N запросов за X минут), мы рекомендуем, чтобы ваш код перехватывал исключение и использовал усеченную экспоненциальную отсрочку , чтобы убедиться, что ваши устройства не создают чрезмерную нагрузку.

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

Пример алгоритма

Алгоритм экспоненциальной отсрочки повторяет запросы экспоненциально, увеличивая время ожидания между повторными попытками до максимального времени отсрочки. Например:

  1. Отправьте запрос к API Google Workspace Events.
  2. Если запрос не выполнен, подождите 1 + random_number_milliseconds и повторите запрос.
  3. Если запрос не выполнен, подождите 2 + random_number_milliseconds и повторите запрос.
  4. Если запрос не выполнен, подождите 4 + random_number_milliseconds и повторите запрос.
  5. И так далее, до maximum_backoff .
  6. Продолжайте ждать и повторять попытки до определенного максимального количества, но не увеличивайте период ожидания между попытками.

где:

  • Время ожидания составляет min(((2^n)+random_number_milliseconds), maximum_backoff) , при этом n увеличивается на 1 для каждой итерации (запроса).
  • random_number_milliseconds — случайное число миллисекунд, меньшее или равное 1000. Это помогает избежать случаев, когда многие клиенты синхронизируются по какой-то ситуации и все повторяют попытки одновременно, отправляя запросы синхронизированными волнами. Значение random_number_milliseconds пересчитывается после каждого повторного запроса.
  • maximum_backoff обычно составляет 32 или 64 секунды. Соответствующее значение зависит от варианта использования.

Клиент может продолжить повторную попытку после достижения maximum_backoff . Повторные попытки после этого момента не требуют дальнейшего увеличения времени отсрочки. Например, если клиент использует время maximum_backoff , равное 64 секундам, то после достижения этого значения клиент может повторять попытку каждые 64 секунды. В какой-то момент клиентам следует запретить повторные попытки на неопределенный срок.

Время ожидания между повторными попытками и количество повторных попыток зависят от вашего варианта использования и условий сети.

Запросить увеличение квоты для каждого проекта

В зависимости от использования ресурсов вашего проекта вы можете запросить увеличение квоты. Вызовы API со стороны учетной записи службы считаются использованием одной учетной записи. Подача заявки на увеличение квоты не гарантирует одобрения. Для утверждения значительного увеличения квоты может потребоваться больше времени.

Не все проекты имеют одинаковые квоты. Поскольку со временем вы все чаще используете Google Cloud, возможно, вам придется увеличить квоты. Если вы ожидаете заметного увеличения использования, вы можете заранее запросить корректировку квот на странице «Квоты» в консоли Google Cloud.

Чтобы узнать больше, посетите следующие ресурсы:

,

Поскольку API Google Workspace Events является общей службой, мы применяем квоты и ограничения, чтобы обеспечить его справедливое использование всеми пользователями и защитить общую производительность Google Workspace.

Если вы превысите квоту, вы получите ответ с кодом состояния HTTP 429: Too many requests . Дополнительные проверки ограничения скорости на серверной части API Google Workspace Events также могут привести к такому же ответу об ошибке. Если возникает эта ошибка, вам следует использовать алгоритм экспоненциальной отсрочки и повторить попытку позже. Пока вы соблюдаете поминутные квоты, указанные в следующих таблицах, количество запросов, которые вы можете делать в день, не ограничено.

Квоты на проект

Квоты для каждого проекта ограничивают частоту запросов для проекта Google Cloud и, таким образом, применяются к одному приложению, вызывающему указанные методы API событий Google Workspace для каждой квоты.

В следующей таблице подробно описаны ограничения запросов для каждого проекта. Вы также можете найти эти ограничения на странице «Квоты» в консоли Google Cloud.

Квота на проект

Методы API событий Google Workspace

Лимит

Пишет в минуту

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

Записей в минуту на пользователя

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

Чтений в минуту

Subscriptions.get

Subscriptions.list

600

Чтений в минуту на пользователя

Subscriptions.get

Subscriptions.list

100

Устранение ошибок квот на основе времени

Для всех ошибок, основанных на времени (максимум N запросов за X минут), мы рекомендуем, чтобы ваш код перехватывал исключение и использовал усеченную экспоненциальную отсрочку , чтобы убедиться, что ваши устройства не создают чрезмерную нагрузку.

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

Пример алгоритма

Алгоритм экспоненциальной отсрочки повторяет запросы экспоненциально, увеличивая время ожидания между повторными попытками до максимального времени отсрочки. Например:

  1. Отправьте запрос к API Google Workspace Events.
  2. Если запрос не выполнен, подождите 1 + random_number_milliseconds и повторите запрос.
  3. Если запрос не выполнен, подождите 2 + random_number_milliseconds и повторите запрос.
  4. Если запрос не выполнен, подождите 4 + random_number_milliseconds и повторите запрос.
  5. И так далее, до maximum_backoff .
  6. Продолжайте ждать и повторять попытки до определенного максимального количества, но не увеличивайте период ожидания между попытками.

где:

  • Время ожидания составляет min(((2^n)+random_number_milliseconds), maximum_backoff) , при этом n увеличивается на 1 для каждой итерации (запроса).
  • random_number_milliseconds — случайное число миллисекунд, меньшее или равное 1000. Это помогает избежать случаев, когда многие клиенты синхронизируются по какой-то ситуации и все повторяют попытки одновременно, отправляя запросы синхронизированными волнами. Значение random_number_milliseconds пересчитывается после каждого повторного запроса.
  • maximum_backoff обычно составляет 32 или 64 секунды. Соответствующее значение зависит от варианта использования.

Клиент может продолжить повторную попытку после достижения maximum_backoff . Повторные попытки после этого момента не требуют дальнейшего увеличения времени отсрочки. Например, если клиент использует время maximum_backoff , равное 64 секундам, то после достижения этого значения клиент может повторять попытку каждые 64 секунды. В какой-то момент клиентам следует запретить повторные попытки на неопределенный срок.

Время ожидания между повторными попытками и количество повторных попыток зависят от вашего варианта использования и условий сети.

Запросить увеличение квоты для каждого проекта

В зависимости от использования ресурсов вашего проекта вы можете запросить увеличение квоты. Вызовы API со стороны учетной записи службы считаются использованием одной учетной записи. Подача заявки на увеличение квоты не гарантирует одобрения. Для утверждения значительного увеличения квоты может потребоваться больше времени.

Не все проекты имеют одинаковые квоты. Поскольку со временем вы все чаще используете Google Cloud, возможно, вам придется увеличить квоты. Если вы ожидаете заметного увеличения использования, вы можете заранее запросить корректировку квот на странице «Квоты» в консоли Google Cloud.

Чтобы узнать больше, посетите следующие ресурсы: