Limites d'utilisation

L'API Google Workspace Events étant un service partagé, nous appliquons des quotas et des limites pour nous assurer que tous les utilisateurs l'utilisent de manière équitable et pour protéger les performances globales de Google Workspace.

Si vous dépassez un quota, vous recevrez un code d'état HTTP 429: Too many requests. Des vérifications supplémentaires de la limite de débit sur le backend de l'API Google Workspace Events peuvent également générer la même réponse d'erreur. Si cette erreur se produit, utilisez un algorithme d'intervalle exponentiel entre les tentatives et réessayez plus tard. Tant que vous respectez les quotas par minute indiqués dans les tableaux suivants, le nombre de requêtes que vous pouvez effectuer par jour n'est pas limité.

Quotas par projet

Les quotas par projet limitent le débit des requêtes pour un projet Google Cloud et s'appliquent donc à une seule application appelant les méthodes d'API Google Workspace Events spécifiées pour chaque quota.

Le tableau suivant détaille les limites de requêtes par projet. Vous pouvez également trouver ces limites sur la page "Quotas" de la console Google Cloud.

Quota par projet

Méthodes de l'API Google Workspace Events

Limite

Écritures par minute

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

600

Écritures par minute et par utilisateur

Subscriptions.create

Subscriptions.patch

Subscriptions.delete

Subscriptions.reactivate

100

Lectures par minute

Subscriptions.get

Subscriptions.list

600

Lectures par minute et par utilisateur

Subscriptions.get

Subscriptions.list

100

Résoudre les erreurs de quota basées sur le temps

Pour toutes les erreurs basées sur le temps (maximum de N requêtes par X minutes), nous vous recommandons de faire en sorte que votre code intercepte l'exception et utilise un intervalle exponentiel entre les tentatives tronqué pour vous assurer que vos appareils ne génèrent pas de charge excessive.

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement d'erreurs pour les applications réseau. Un algorithme de temporisation de retransmission relance les requêtes en augmentant de manière exponentielle le temps d'attente entre les requêtes jusqu'à ce que la durée maximale de l'intervalle soit atteinte. Si les requêtes échouent toujours, il est important que les délais entre les requêtes augmentent au fil du temps jusqu'à ce que la requête aboutisse.

Exemple d'algorithme

Un algorithme de temporisation de retransmission relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives jusqu'à ce que la durée maximale de la temporisation de retransmission soit atteinte. Exemple :

  1. Effectuez une requête auprès de l'API Google Workspace Events.
  2. Si la requête échoue, attendez 1 + random_number_milliseconds, puis réessayez la requête.
  3. Si la requête échoue, attendez 2 + random_number_milliseconds, puis réessayez la requête.
  4. Si la requête échoue, attendez 4 + random_number_milliseconds, puis réessayez la requête.
  5. Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.
  6. Continuez d'attendre et de réessayer jusqu'à un nombre maximal de tentatives, mais n'augmentez pas le délai d'attente entre les tentatives.

où :

  • Le temps d'attente est défini sur min(((2^n)+random_number_milliseconds), maximum_backoff), avec n incrémenté de 1 pour chaque itération (requête).
  • random_number_milliseconds est un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cela permet d'éviter les cas où de nombreux clients se retrouvent synchronisés pour une raison quelconque et effectuent tous une nouvelle tentative en même temps, en envoyant des requêtes par vagues synchronisées. La valeur de random_number_milliseconds est recalculée après chaque requête de nouvelle tentative.
  • La valeur maximum_backoff est généralement définie sur 32 ou 64 secondes. La valeur appropriée dépend du cas d'utilisation.

Le client peut continuer à réessayer une fois qu'il a atteint la durée maximum_backoff. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Par exemple, si un client utilise une durée maximum_backoff de 64 secondes, il peut réessayer toutes les 64 secondes une fois cette valeur atteinte. À un moment donné, les clients doivent être empêchés de réessayer indéfiniment.

Le temps d'attente entre les nouvelles tentatives et le nombre de tentatives dépendent de votre cas d'utilisation et des conditions du réseau.

Demander une augmentation du quota par projet

Selon l'utilisation des ressources de votre projet, vous pouvez demander un ajustement de quota. Les appels d'API effectués par un compte de service sont considérés comme utilisant un seul compte. La demande d'ajustement de quota ne garantit pas l'approbation. Les demandes d'ajustement de quota qui augmenteraient considérablement la valeur du quota peuvent nécessiter plus de temps pour être approuvées.

Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que vous utilisez Google Cloud au fil du temps, il peut être nécessaire d'augmenter vos valeurs de quota. Si vous prévoyez une augmentation significative de votre utilisation, vous pouvez anticiper cette évolution en demandant des ajustements de quotas sur la page Quotas de la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :