Limites d'utilisation

L'API Google Chat étant un service partagé, nous appliquons des quotas et des limites veillez à ce qu'il soit utilisé équitablement par tous les utilisateurs et pour protéger l'ensemble les performances de Google Workspace.

Si vous dépassez un quota, vous recevez une requête HTTP 429: Too many requests ou la réponse du code d'état. Vérifications supplémentaires des limites de débit dans Chat peut également générer la même réponse d'erreur. Si cette erreur se produit, vous doit utiliser un algorithme d'intervalle exponentiel entre les tentatives et réessayez plus tard. Tant que vous respectez les quotas par minute indiqués dans dans les tableaux suivants, le nombre de requêtes que vous pouvez envoyer n'est pas limité par jour.

Deux types de quotas s'appliquent aux méthodes de l'API Chat: par espace et par projet. des quotas.

Quotas par espace

Les quotas par espace limitent le taux de requêtes dans un espace donné et sont partagés entre toutes les applications Chat utilisées dans cet espace qui appelle Méthodes de l'API Chat pour chaque quota.

Le tableau suivant détaille les limites de requêtes par espace:

Quota par espace

Méthodes de l'API Chat

Limite (toutes les 60 secondes,
partagée entre toutes les applications Chat de l'espace)

Lectures par minute

media.download

spaces.get

spaces.members.get

spaces.members.list

spaces.messages.get

spaces.messages.list

spaces.messages.attachments.get

spaces.messages.reactions.list

900

Écritures par minute

media.upload

spaces.delete

spaces.patch

spaces.messages.create (s'applique également aux webhooks entrants)

spaces.messages.delete

spaces.messages.patch

spaces.messages.reactions.create

spaces.messages.reactions.delete

60

Quotas par projet

Les quotas par projet limitent le taux de requêtes pour un projet Google Cloud. s'appliquent donc à une seule application Chat qui appelle Méthodes de l'API Chat pour chaque quota.

Le tableau suivant détaille les limites de requêtes par projet. Vous trouverez également ces limites sur la page Quotas.

Quota par projet

Méthodes de l'API Chat

Limite (toutes les 60 secondes)

Écritures de messages par minute

spaces.messages.create

spaces.messages.patch

spaces.messages.delete

3000

Lectures de messages par minute

spaces.messages.get

spaces.messages.list

3000

Écritures des membres par minute

spaces.members.create

spaces.members.delete

300

Lectures d'abonnements par minute

spaces.members.get

spaces.members.list

3000

Espaces écrits par minute

spaces.setup

spaces.create

spaces.patch

spaces.delete

60

Lectures d'espace par minute

spaces.get

spaces.list

spaces.findDirectMessage

3000

Écritures de pièces jointes par minute

media.upload

600

Lectures de pièces jointes par minute

spaces.messages.attachments.get

media.download

3000

Écritures de réaction par minute

spaces.messages.reactions.create

spaces.messages.reactions.delete

600

Lectures de réaction par minute

spaces.messages.reactions.list

3000

Limites d'utilisation supplémentaires

Des limites de quota supplémentaires s'appliquent à la création d'espaces de type GROUP_CHAT ou SPACE (à l'aide de la méthode spaces.create ou spaces.setup). Créer moins de 35 espaces par minute et 210 espaces par minute par heure de ces types. Les espaces de type DIRECT_MESSAGE ne sont pas concernés par ces des limites de quota supplémentaires.

Les requêtes volumineuses par seconde (RPS) de toute API ciblant le même espace peuvent déclencher des limites internes supplémentaires qui ne sont pas visibles dans Quotas.

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

Pour toutes les erreurs temporelles (N requêtes maximum toutes les X minutes), nous recommandons votre code détecte l'exception et utilise un intervalle exponentiel entre les tentatives tronqué pour vous assurer que votre ne génèrent pas de charge excessive.

L'intervalle exponentiel entre les tentatives est une stratégie standard de traitement des erreurs pour les applications réseau. Une L'algorithme d'intervalle exponentiel entre les tentatives relance les requêtes en utilisant des temps d'attente croissants de manière exponentielle entre les requêtes, jusqu'à un intervalle maximal entre les tentatives. Si les demandes n'aboutissent toujours pas, 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 d'intervalle exponentiel entre les tentatives relance les requêtes de manière exponentielle, en augmentant le temps d'attente entre les tentatives, jusqu'à un intervalle maximal entre les tentatives. Exemple :

  1. Envoyez une requête à l'API Google Chat.
  2. Si la requête échoue, attendez 1 + random_number_milliseconds, puis réessayez. la demande.
  3. Si la requête échoue, attendez 2 + random_number_milliseconds, puis réessayez. la demande.
  4. Si la requête échoue, attendez 4 + random_number_milliseconds, puis réessayez. la demande.
  5. Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.
  6. Continuez à attendre et à relancer la requête jusqu'à atteindre le nombre maximal de tentatives, mais n'augmentez pas le temps d'attente entre les tentatives.

où :

  • Le temps d'attente est de 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 sont synchronisés par une situation donnée et tous effectuent une nouvelle tentative en même temps, en envoyant les requêtes de manière synchronisée les vagues. La valeur de random_number_milliseconds est recalculée après chaque nouvelle tentative de requête.
  • 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 à effectuer de nouvelles tentatives une fois l'heure maximum_backoff atteinte. Au-delà de ce point, il n'est pas nécessaire de continuer à augmenter la durée de l'intervalle exponentiel entre les tentatives. Pour Par exemple, si un client utilise une durée maximum_backoff de 64 secondes, une fois cette valeur, le client peut réessayer toutes les 64 secondes. À un moment donné, les clients ne doivent pas pouvoir effectuer de nouvelles tentatives indéfiniment.

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

Demander une augmentation de quota par projet

En fonction de l'utilisation des ressources de votre projet, vous pouvez demander un quota augmenter. Les appels d'API effectués par un compte de service sont considérés comme utilisant un seul compte. La demande d'augmentation de quota ne garantit pas l'approbation. Grande L'approbation des augmentations de quota peut prendre plus de temps.

Tous les projets ne sont pas soumis aux mêmes quotas. Alors que vous utilisez de plus en plus Google Cloud vous devrez peut-être augmenter vos quotas. Si vous vous attendez à ce que l'augmentation de l'utilisation, vous pouvez demander des ajustements de quotas sur la page Quotas dans la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :