Cette page a été traduite par l'API Cloud Translation.

Quotas

Les quotas protègent l'infrastructure de Google contre les processus automatisés qui utilisent l'API Google Bid Manager de manière inappropriée. Elles garantissent que les actions d'un développeur ne peuvent pas avoir d'impact négatif sur l'ensemble de la communauté.

Limites de quota

Les limites de quota par défaut suivantes sont partagées par toutes les ressources et méthodes de l'API Bid Manager.

2 000 requêtes par projet et par jour (possibilité d'augmenter le nombre de requêtes autorisées)
4 requêtes par seconde (RPS) par projet
- Dans la console Google APIs, ce quota est appelé Requêtes par minute et par utilisateur, et il est défini sur 240.

Dépassement des limites de quota

Dans le cas peu probable où votre requête échouerait en raison du dépassement d'une limite de quota, l'API renverra un code d'état HTTP ainsi que le motif de l'erreur. De plus, le corps de la réponse contient une description détaillée de la cause de l'erreur. Consultez le guide Messages d'erreur pour obtenir un exemple de réponse d'erreur.

La liste suivante présente les erreurs possibles et les actions recommandées pour les échecs de requêtes causés par un dépassement des limites de quota.

Code	Motif	Message	Action recommandée
403	dailyLimitExceeded	Limite quotidienne dépassée	Ne relancez pas la requête avant d'avoir résolu le problème. Évaluez votre utilisation dans la console Google APIs et modifiez votre workflow pour réduire le nombre de requêtes. Vous pouvez demander un quota supplémentaire si vous pensez que votre utilisation est raisonnable.
403	userRateLimitExceeded	Limite de débit utilisateur dépassée	Ralentissez la fréquence à laquelle vous envoyez des requêtes en utilisant un intervalle exponentiel entre les tentatives.

Qu'est-ce que l'intervalle exponentiel entre les tentatives ?

L'intervalle exponentiel entre les tentatives est une stratégie standard en matière de traitement d'erreurs pour les applications réseau, selon laquelle le client relance périodiquement une requête ayant échoué sur une durée de plus en plus longue. Si un volume élevé de requêtes ou un trafic réseau important provoquent des erreurs sur le serveur, l'intervalle exponentiel entre les tentatives peut s'imposer comme une stratégie efficace pour traiter ces erreurs. À l'inverse, cette stratégie n'est pas pertinente pour traiter les erreurs sans rapport avec le volume réseau ou les temps de réponse, telles que les erreurs associées aux identifiants d'autorisation non valides ou aux fichiers introuvables.

Utilisé correctement, l'intervalle exponentiel entre les tentatives augmente l'efficacité de l'utilisation de la bande passante, réduit le nombre de requêtes nécessaires pour obtenir une réponse positive et optimise le débit des requêtes dans les environnements avec simultanéité.

Le fonctionnement de l'intervalle exponentiel simple entre les tentatives se présente comme suit :

Vous envoyez une requête à l'API.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 1 seconde + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 2 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 4 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 8 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous recevez une réponse HTTP 503, qui indique que vous devez relancer la requête.
Vous patientez 16 secondes + "random_number_milliseconds", puis vous relancez la requête.
Vous arrêtez, puis vous signalez ou consignez une erreur.

Dans le flux ci-dessus, "random_number_milliseconds" correspond à un nombre aléatoire de millisecondes inférieur ou égal à 1 000. Cette valeur est nécessaire, car l'introduction d'un petit délai aléatoire aide à répartir la charge de manière plus uniforme et à éviter la surcharge du serveur. La valeur de "random_number_milliseconds" doit être redéfinie après chaque temps d'attente.

Remarque : L'attente correspond toujours à (2 ^ n) + "random_number_milliseconds", où "n" est un entier augmentant de manière monotone défini initialement sur 0. L'entier "n" est augmenté de 1 pour chaque itération (chaque requête).

L'algorithme est configuré pour se terminer lorsque "n" vaut 5. Ce plafond empêche les clients d'effectuer des relances indéfiniment et entraîne un délai total d'environ 32 secondes avant qu'une requête ne soit considérée comme une "erreur non récupérable". Vous pouvez tout à fait définir un nombre maximal de tentatives plus élevé, surtout si une longue importation est en cours d'exécution. Veillez simplement à limiter le délai des nouvelles tentatives de manière raisonnable, par exemple à moins d'une minute.

Demander un quota quotidien supplémentaire

Si vous pensez que votre application nécessite un quota quotidien supplémentaire, vous pouvez en demander plus en suivant les instructions ci-dessous.

Les instructions suivantes ne s'appliquent qu'aux projets qui ont rencontré une erreur dailyLimitExceeded. Les actions recommandées pour les autres erreurs de quota sont décrites dans le tableau ci-dessus.

Accédez à l'API Bid Manager dans la console Google APIs.
Examinez vos statistiques d'utilisation à partir de la page Métriques pour vous assurer que votre application fonctionne comme prévu. Portez une attention particulière aux méthodes appelées et corrigez toute utilisation inattendue ou excessive avant de continuer.
Si l'utilisation semble normale, accédez à la page Quotas, cliquez sur l'icône de modification à côté de Requêtes par jour, puis sur le lien "Demander un quota supérieur".

Veillez à consulter les informations et à suivre les instructions incluses dans le formulaire de demande de quota avant d'envoyer une demande d'augmentation.