L'API Google Ads applique une limitation du débit par requêtes par seconde (RPS) aux ID client et aux projets Google Cloud de manière indépendante. En plus des requêtes par minute (qui mesurent la fréquence des appels d'API), l'API Google Ads applique également des limites aux opérations par minute (qui mesurent le nombre total d'opérations d'API dans les requêtes). L'API Google Ads utilise un algorithme de token bucket pour mesurer les requêtes et déterminer une limite de RPS appropriée. La limite exacte varie donc en fonction de la charge globale du serveur à un moment donné.
L'objectif de l'imposition de limites de débit est d'empêcher un utilisateur de perturber le service pour les autres utilisateurs en submergeant (intentionnellement ou non) les serveurs de l'API Google Ads avec un volume élevé de requêtes.
Les requêtes qui ne respectent pas les limites de débit sont refusées avec l'erreur:
RESOURCE_TEMPORARILY_EXHAUSTED.
Vous pouvez contrôler votre application et atténuer les limites de débit en réduisant activement le nombre de requêtes et en limitant les RPS côté client.
Il existe plusieurs façons de réduire les risques de dépassement de la limite de débit. Vous familiariser avec les concepts Enterprise Integration Patterns (EIP) tels que la messagerie, la nouvelle diffusion et la limitation peut vous aider à créer une application cliente plus robuste.
Les bonnes pratiques recommandées suivantes sont classées par ordre de complexité, les stratégies les plus simples en haut et les architectures plus robustes, mais sophistiquées, en bas :
- Intervalle exponentiel entre les tentatives
- Limiter les tâches simultanées
- Requêtes par lot
- Limitation et limiteurs de débit
- Mise en file d'attente
Intervalle exponentiel entre les tentatives
Lorsque votre application reçoit une
RESOURCE_TEMPORARILY_EXHAUSTED erreur, utilisez une
stratégie d'intervalle exponentiel entre les tentatives avec une gigue aléatoire avant de réessayer la
requête ayant échoué. L'intervalle exponentiel entre les tentatives augmente progressivement le temps d'attente entre les tentatives (par exemple, en attendant 2 secondes, puis 4 secondes, puis 8 secondes, plus un petit délai aléatoire), ce qui permet à la charge du serveur et aux buckets de quota de récupérer tout en empêchant les pics de nouvelles tentatives synchronisées sur les instances clientes.
Limiter les tâches simultanées
L'une des causes profondes du dépassement des limites de débit est que l'application cliente génère un nombre excessif de tâches parallèles. Bien que nous ne limitions pas le nombre de requêtes parallèles qu'une application cliente peut avoir, cela peut dépasser la limite de requêtes par seconde au niveau du projet Google Cloud.
Il est recommandé de définir une limite supérieure raisonnable pour le nombre total de tâches simultanées qui vont effectuer des requêtes (sur tous les processus et toutes les machines), et d'ajuster cette limite à la hausse pour optimiser votre débit sans dépasser la limite de débit.
Vous pouvez également envisager de limiter les RPS côté client (voir Limitation et limiteurs de débit).
Requêtes par lot
Envisagez de regrouper plusieurs opérations dans une seule requête. Cela s'applique principalement aux appels Mutate pour différents services. Par exemple, si vous mettez à jour l'état de plusieurs instances de AdGroupAd, vous pouvez appeler MutateAdGroupAds une seule fois et transmettre plusieurs operations au lieu d'appeler MutateAdGroupAds une seule fois pour chaque AdGroupAd. Consultez nos
conseils sur les opérations par lot pour obtenir d'autres
exemples.
Bien que les requêtes par lot réduisent le nombre total d'appels d'API et atténuent les limitations du débit sur les requêtes par minute, elles peuvent déclencher la limite de débit des opérations par minute si vous effectuez un grand nombre d'opérations sur un seul compte.
Limitation et limiteurs de débit
En plus de limiter le nombre total de threads dans votre application, vous pouvez également implémenter des limiteurs de débit côté client. Cela garantit que tous les threads de vos processus, clusters ou les deux sont régis par une limite de RPS spécifique côté client.
Consultez le RateLimiter Guava ou implémentez votre propre algorithme de token bucket pour un environnement en cluster. Par exemple, vous pouvez gérer les jetons dans un datastore en mémoire distribué à faible latence tel que Redis ou Memcached, où chaque client acquiert et consomme un jeton avant de traiter une requête. Si les jetons sont épuisés, le client attend que le prochain lot de jetons soit réapprovisionné.
Mise en file d'attente
Une file d'attente de messages est la solution pour la distribution de la charge d'opération, tout en contrôlant les taux de requêtes et de consommateurs. Plusieurs options de file d'attente de messages sont disponibles (certaines Open Source, d'autres propriétaires), et la plupart d'entre elles peuvent fonctionner avec différentes langues.
Lorsque vous utilisez des files d'attente de messages, vous pouvez avoir plusieurs producteurs qui envoient des messages à la file d'attente et plusieurs consommateurs qui traitent ces messages. Les limites peuvent être implémentées côté consommateur en limitant le nombre de consommateurs simultanés, ou en implémentant des limiteurs de débit ou des limites pour les producteurs ou les consommateurs.
Par exemple, si un consommateur de messages rencontre une erreur de limitation du débit, il peut renvoyer la requête à la file d'attente avec un délai de nouvelle tentative standardisé (à l'aide d'un intervalle exponentiel entre les tentatives) et mettre à jour une boucle de rétroaction de limiteur de débit partagée afin que tous les consommateurs réduisent automatiquement leur taux de traitement tout en récupérant de l'erreur.