Limites de débit
L'API Google Ads regroupe les requêtes pour la limitation du débit par 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 permet d'éviter qu'un utilisateur perturbe le service pour les autres utilisateurs en submergeant les serveurs d'API Google Ads d'un volume élevé de requêtes (intentionnellement ou non).
Les requêtes qui ne respectent pas les limites de débit sont refusées avec l'erreur suivante : RESOURCE_TEMPORARILY_EXHAUSTED.
Vous pouvez prendre le contrôle de 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 moyens de réduire le risque de dépasser la fréquence limite. Familiarisez-vous avec les concepts des modèles d'intégration d'entreprise (EIP), tels que la messagerie, la nouvelle diffusion et la limitation, peut vous aider à créer une application cliente plus robuste.
Les pratiques recommandées suivantes sont classées par complexité, avec des stratégies plus simples en premier et des architectures plus robustes mais sophistiquées par la suite:
- Limiter les tâches simultanées
- Traiter des requêtes par lot
- Limitation et limiteur de fréquence
- Mise en file d'attente
Limiter les tâches simultanées
L'une des causes principales 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 recevoir, cela peut facilement dépasser la limite de requêtes par seconde définie au niveau du jeton de développeur.
Il est recommandé de définir 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 machines), et d'augmenter la limite pour optimiser le 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 limiteur de fréquence).
Requêtes par lot
Envisagez de regrouper plusieurs opérations dans une seule requête. Ceci est particulièrement utile pour les 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 seule fois et transmettre plusieurs operations. Consultez nos instructions sur les opérations par lot pour obtenir des exemples supplémentaires.
Bien que les requêtes par lot réduisent le nombre total de requêtes et atténuent la limite de débit des requêtes par minute, cela peut déclencher la limite du taux d'opérations par minute si vous effectuez un grand nombre d'opérations sur un seul compte.
Limitation et limiteur de fréquence
En plus de limiter le nombre total de threads dans votre application cliente, vous pouvez mettre en œuvre des limiteurs de débit côté client. Cela permet de garantir 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 utiliser le 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é utilisés, le client devrait attendre que le prochain lot de jetons soit généré.
Mise en file d'attente
Une file d'attente de messages est la solution permettant de répartir la charge des opérations, tout en contrôlant les taux de requêtes et de consommateurs. Il existe un certain nombre d'options de file d'attente de messages disponibles (certaines Open Source et 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 des messages à la file d'attente et plusieurs consommateurs peuvent traiter ces messages. Vous pouvez mettre en œuvre des limitations côté consommateur en limitant le nombre de consommateurs simultanés, ou mettre en œuvre des limiteurs de fréquence ou des régulateurs 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 pour une nouvelle tentative. En parallèle, ce consommateur peut également demander à tous les autres consommateurs de suspendre le traitement pendant un certain nombre de secondes afin de corriger l'erreur.