Limites de débit
L'API Google Ads regroupe les requêtes de limitation de débit par requêtes par seconde (RPS) par ID client (CID) et jeton de développeur. Cela signifie que la facturation est appliquée indépendamment aux ID client et aux jetons de développeur. L'API Google Ads utilise un algorithme 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 d'imposer des limites de débit est d'empêcher un utilisateur de perturber le service pour d'autres utilisateurs en saturant (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 le débit par seconde 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 des modèles d'intégration d'entreprise (EIP), tels que la messagerie, la nouvelle diffusion et le débit limité, pour créer une application cliente plus robuste.
Les bonnes pratiques recommandées suivantes sont classées par complexité, les stratégies plus simples en haut et les architectures plus robustes, mais sophistiquées, ensuite:
- 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 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 effectuer, cela peut facilement dépasser la limite de requêtes par seconde au niveau du jeton du développeur.
Nous vous recommandons de définir une limite supérieure raisonnable pour le nombre total de tâches simultanées qui vont envoyer des requêtes (pour tous les processus et 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 le RPS côté client (consultez la section 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 fois et transmettre plusieurs operations. Pour obtenir d'autres exemples, consultez nos conseils sur les opérations par lot.
Bien que le traitement par lot des requêtes réduise 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.
Limites de débit et 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 permet de s'assurer que tous les threads de vos processus et / ou de vos clusters sont régis par une limite QPS spécifique côté client.
Vous pouvez consulter Guava Rate Limiter ou implémenter votre propre algorithme basé sur un bucket de 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 devra alors acquérir et consommer un jeton avant de traiter la requête. Si les jetons ont été utilisés, le client doit attendre que le prochain lot de jetons soit généré.
Mise en file d'attente
Une file de messages est la solution pour la répartition de la charge des opérations, tout en contrôlant les taux de requêtes et de consommation. Plusieurs options de file d'attente de messages sont disponibles (certaines Open Source, d'autres propriétaires), et bon nombre 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 les traitent. Les limitations 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 limiteurs 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 réessayée. En même temps, ce consommateur peut également informer tous les autres consommateurs de suspendre le traitement pendant un certain nombre de secondes pour récupérer de l'erreur.