Limites de débit

L'API Google Ads regroupe les requêtes pour limiter le débit par requêtes par seconde (RPS) par ID client (CID) et jeton de développeur. Cela signifie que la mesure est appliquée indépendamment aux CID et aux jetons de développeur. L'API Google Ads utilise un algorithme de compartiment à 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'objectif de l'imposition de limites de débit est d'empêcher un utilisateur de perturber le service pour les autres utilisateurs en surchargeant (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 seront rejeté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 des modèles d'intégration d'entreprise (EIP, Enterprise Integration Patterns) tels que la messagerie, la nouvelle livraison et la limitation peut vous aider à créer une application cliente plus robuste.

Voici les pratiques recommandées, classées par ordre de complexité, avec les stratégies les plus simples en haut et les architectures plus robustes, mais sophistiquées, en bas :

• Limiter les tâches simultanées
• Effectuer des requêtes par lot
• Limitation et limiteurs de débit
• Mise en file d'attente

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 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 effectuer des requêtes (sur tous les processus et toutes les machines), et d'ajuster cette limite vers le haut pour optimiser votre débit sans dépasser la limite de débit.

Vous pouvez également envisager de limiter les RPS côté client (consultez Limitation et limiteurs de débit).

Effectuer des requêtes par lot

Envisagez de regrouper plusieurs opérations dans une seule requête. Cela s'applique principalement 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 seule fois et transmettre plusieurs operations. Pour obtenir d'autres exemples, consultez nos conseils sur les opérations par lot.

Bien que le regroupement des requêtes réduise le nombre total de requêtes et atténue la limite de débit de requêtes par minute, il peut déclencher la limite de débit d'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 cliente, vous pouvez également implémenter des limiteurs de débit côté client. Cela peut 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 consulter Guava Rate Limiter ou implémenter votre propre algorithme basé sur un compartiment à jetons pour un environnement en cluster. Par exemple, vous pouvez générer des jetons et les stocker dans un stockage transactionnel partagé, tel qu'une base de données. Chaque client devra acquérir et consommer un jeton avant de traiter la requête. Si les jetons sont épuisés, le client devra attendre la génération du prochain lot de jetons.

Mise en file d'attente

Une file d'attente de messages est la solution pour la répartition 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 beaucoup 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. Des 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 limite de débit, il peut renvoyer la requête à la file d'attente pour qu'elle soit retentée. En même temps, ce consommateur peut également notifier à tous les autres consommateurs de mettre en pause le traitement pendant un certain nombre de secondes pour se remettre de l'erreur.