Limites d'utilisation

L'API Google Vault étant un service partagé, nous appliquons des quotas et des limites pour nous assurer qu'elle est utilisée de manière équitable par tous les utilisateurs et pour protéger l'état général du système Google Workspace.

Limites liées aux produits

Vous ne pouvez pas autoriser plus de 20 exportations en cours dans votre organisation.

Quotas de requêtes API

Chaque organisation est autorisée à effectuer 600 lectures Matter par minute, pour l'ensemble des projets et des utilisateurs, y compris les requêtes via l'API Vault et vault.google.com.

Les tableaux suivants répertorient les limites de requêtes par minute et par projet :

Requêtes de lecture par minute et par projet
Exporter, affaire et requête enregistrée 120
En attente 228
Opération de longue durée 300
Requêtes d'écriture par minute et par projet
Exporter 20
En attente 60
Autorisations Matter 30
Matter 60
Requête enregistrée 45
Requêtes de recherche (nombre) par minute et par projet
Nombre de recherches 20

Utilisation des quotas par méthode

Le quota utilisé par une requête dépend de la méthode appelée. Le tableau suivant indique l'utilisation du quota par méthode :

Méthode Coûts de quota
matters.close
matters.create
matters.delete
matters.reopen
matters.update
matters.undelete 		1 litige lu
1 litige écrit
matters.count 1 unité
matters.get 1 litige lu
matters.list 10 lectures de litiges
matters.addPermissions
matters.removePermissions 		1 lecture Matter
1 écriture Matter
1 écriture des autorisations Matter
matters.exports.create 1 lecture d'exportation
10 écritures d'exportation
matters.exports.delete 1 écriture d'exportation
matters.exports.get 1 exportation lue
matters.exports.list 5 lectures d'exportation
matters.holds.addHeldAccounts
matters.holds.create
matters.holds.delete
matters.holds.removeHeldAccounts
matters.holds.update 		1 lecture de problème
1 écriture de problème
1 lecture de préservation à titre conservatoire
1 écriture de préservation à titre conservatoire
matters.holds.list 1 lecture Matter
3 lectures de maintien
matters.holds.accounts.create
matters.holds.accounts.delete
matters.holds.accounts.list 		1 lecture de problème
1 écriture de problème
1 lecture de préservation à titre conservatoire
1 écriture de préservation à titre conservatoire
matters.savedQueries.create
matters.savedQueries.delete 		1 lecture de problème
1 écriture de problème
1 lecture de requête enregistrée
1 écriture de requête enregistrée
matters.savedQueries.get 1 lecture de requête
1 lecture de requête enregistrée
matters.savedQueries.list 1 lecture Matter
3 lectures de requêtes enregistrées
operations.get 1 opération de lecture de longue durée

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

Si vous dépassez un quota par minute ou par organisation, vous recevez généralement un code d'état HTTP 429: Too many requests en réponse.

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

L'intervalle exponentiel entre les tentatives est une stratégie standard de gestion des exceptions pour les applications réseau. Un algorithme d'intervalle exponentiel entre les tentatives 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 exponentiel 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 d'intervalle exponentiel entre les tentatives 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 l'intervalle exponentiel soit atteinte. Exemple :

  1. Envoyez une requête à l'API Google Vault.
  2. Si la requête échoue, attendez 1 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
  3. Si la requête échoue, attendez 2 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
  4. Si la requête échoue, attendez 4 + random_number_milliseconds secondes, puis effectuez une nouvelle tentative.
  5. Poursuivez ainsi jusqu'à atteindre la valeur maximum_backoff.
  6. Continuez d'attendre et de 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 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 correspond à 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 nouvelle tentative de la 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 des nouvelles tentatives après avoir atteint le temps 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 un délai maximum_backoff de 64 secondes, une fois celui-ci atteint, il peut effectuer une nouvelle tentative toutes les 64 secondes. À un certain moment, vous devez empêcher les clients d'effectuer des tentatives à l'infini.

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

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 prendre plus de temps à être approuvées.

Tous les projets ne sont pas soumis aux mêmes quotas. À mesure que votre utilisation de Google Cloud s'accroît, vous devrez peut-être augmenter vos quotas. Si vous prévoyez une augmentation notable de l'utilisation, vous pouvez anticiper cette évolution en demandant des ajustements de quota sur la page Quotas de la console Google Cloud.

Pour en savoir plus, consultez les ressources suivantes :

Tarifs

L'utilisation de l'API Google Vault est disponible sans frais supplémentaires pour les clients Google Workspace.