Limites de débit
L'API Google Ads regroupe les requêtes de limitation du débit en fonction du nombre de requêtes par seconde (RPS) par numéro client (CID) et jeton de développeur, ce qui signifie que la mesure est appliquée indépendamment des numéros client et des jetons de développeur. L'API Google Ads utilise un algorithme de seau à jetons 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'imposition de limites de débit a pour but d'empêcher un utilisateur d'interrompre le service pour d'autres utilisateurs en submergeant (intentionnellement ou non) les serveurs de l'API Google Ads avec un grand nombre de demandes.
Les requêtes qui ne respectent pas les limites de débit sont rejetées avec l'erreur suivante : RESOURCE_TEMPORARILY_EXHAUSTED.
Vous pouvez prendre le contrôle de votre application et atténuer les limites de taux 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épasser la limite de débit. Familiarisez-vous avec les concepts EIP (Enterprise Integration schémas) tels que la messagerie, la nouvelle distribution et la limitation de la bande passante pour créer une application cliente plus robuste.
Les pratiques recommandées suivantes sont classées par complexité, avec des stratégies plus simples en haut et des architectures plus robustes mais sophistiquées ensuite:
- Limiter les tâches simultanées
- Requêtes par lot
- Limitation et limiteurs de fréquence
- Mise en file d'attente
Limiter les tâches simultanées
L'une des causes 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 facilement dépasser la limite du nombre de requêtes par seconde au niveau du jeton de développeur.
Il est recommandé de fixer une limite supérieure raisonnable pour le nombre total de tâches simultanées qui vont envoyer des requêtes (sur tous les processus et toutes les machines), et de l'ajuster à la hausse pour optimiser votre débit sans dépasser la limite de débit.
De plus, vous pouvez envisager de limiter les RPS côté client (consultez la section Limitation et limiteurs de débit).
Requêtes par lot
Envisagez de regrouper plusieurs opérations dans une seule requête. Cela s'applique surtout aux appels MutateFoo. Par exemple, si vous mettez à jour l'état de plusieurs instances de AdGroupAd, au lieu d'appeler MutateAdGroupAds une fois pour chaque AdGroupAd, vous pouvez appeler MutateAdGroupAds une fois et transmettre plusieurs operations. Reportez-vous à nos conseils sur les opérations par lot pour obtenir des exemples supplémentaires.
Bien que le traitement des requêtes par lot réduit le nombre total de requêtes et atténue la limite de débit des requêtes par minute, il peut 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 fréquence
En plus de limiter le nombre total de threads dans votre application cliente, vous pouvez également mettre en œuvre des limiteurs de fréquence côté client. Cela peut vous assurer que tous les threads de vos processus et / ou clusters sont régis par une limite de RPS spécifique côté client.
Vous pouvez vous servir du limiteur de fréquence Guava ou implémenter votre propre algorithme basé sur un seau à jetons pour un environnement en cluster. Par exemple, vous pouvez générer des jetons et les stocker dans un espace de stockage transactionnel partagé tel qu'une base de données. Chaque client doit acquérir et consommer un jeton avant de traiter la requête. Si les jetons ont été épuisés, le client doit attendre que le lot suivant de jetons soit généré.
Mise en file d'attente
Une file d'attente de messages permet de répartir la charge des opérations, tout en contrôlant les tarifs des requêtes et des clients. Il existe un certain nombre d'options de file d'attente de messages (certaines en Open Source, d'autres propriétaires) et nombre d'entre elles peuvent fonctionner avec différents langages.
Lorsque vous utilisez des files d'attente de messages, plusieurs producteurs peuvent envoyer les messages à la file d'attente et plusieurs consommateurs peuvent les traiter. Des limitations peuvent être mises en œuvre côté consommateur en limitant le nombre de consommateurs simultanés, ou en implémentant des limiteurs de fréquence ou des limitations pour les producteurs ou les consommateurs.
Par exemple, si un consommateur de messages rencontre une erreur de limite de débit, il peut renvoyer la requête à la file d'attente pour une nouvelle tentative. Dans le même temps, ce client peut également demander à tous les autres consommateurs de suspendre le traitement pendant un certain nombre de secondes afin de corriger l'erreur.