L'API Google Ads applica la limitazione di frequenza in base alle query al secondo (QPS) sia agli ID cliente sia ai progetti Google Cloud in modo indipendente. Oltre alle richieste al minuto (che misurano la frequenza delle chiamate API), l'API Google Ads applica anche limiti alle operazioni al minuto (che misurano il numero totale di operazioni API nelle richieste). L'API Google Ads utilizza un algoritmo bucket di token per misurare le richieste e determinare un limite di QPS appropriato, pertanto il limite esatto varia a seconda del carico complessivo del server in un determinato momento.
Lo scopo dell'imposizione dei limiti di frequenza è impedire a un utente di interrompere il servizio per altri utenti sovraccaricando (intenzionalmente o meno) i server dell'API Google Ads con un volume elevato di richieste.
Le richieste che violano i limiti di frequenza vengono rifiutate con l'errore:
RESOURCE_TEMPORARILY_EXHAUSTED.
Puoi controllare la tua app e mitigare i limiti di frequenza riducendo attivamente il numero di richieste e limitando le QPS dal lato client.
Esistono diversi modi per ridurre le probabilità di superare il limite di frequenza. Acquisire familiarità con i concetti di Enterprise Integration Patterns (EIP) come la messaggistica, la nuova consegna e la limitazione può aiutarti a creare un' app client più solida.
Le seguenti pratiche consigliate sono ordinate in base alla complessità, con le strategie più semplici in alto e le architetture più solide ma sofisticate a seguire:
- Backoff esponenziale
- Limita le attività simultanee
- Creazione di richieste batch
- Limitazione e limitatori di frequenza
- Coda
Backoff esponenziale
Quando l'applicazione riceve un
RESOURCE_TEMPORARILY_EXHAUSTED errore, utilizza una
norma di backoff esponenziale con jitter casuale prima di riprovare a inviare la richiesta
non riuscita. Il backoff esponenziale aumenta progressivamente il tempo di attesa tra i tentativi (ad esempio, attendendo 2 secondi, poi 4 secondi, poi 8 secondi, più un piccolo ritardo casuale), consentendo al carico del server e ai bucket di quota di recuperare, evitando al contempo picchi di tentativi sincronizzati tra le istanze client.
Limita le attività simultanee
Una delle cause principali del superamento dei limiti di frequenza è che l'app client genera un numero eccessivo di attività parallele. Sebbene non limitiamo il numero di richieste parallele che un'app client può avere, questo può superare il limite di richieste al secondo a livello di progetto Google Cloud.
Ti consigliamo di impostare un limite superiore ragionevole per il numero totale di attività simultanee che effettueranno richieste (in tutti i processi e le macchine) e di aumentare il valore per ottimizzare la velocità effettiva senza superare il limite di frequenza.
Inoltre, puoi prendere in considerazione la limitazione delle QPS dal lato client (vedi Limitazione e limitatori di frequenza).
Creazione di richieste batch
Valuta la possibilità di raggruppare più operazioni in un'unica richiesta. Questo è più applicabile alle chiamate Mutate per vari servizi. Ad esempio, se stai
aggiornando lo stato di più istanze di AdGroupAd, puoi
chiamare MutateAdGroupAds una volta e passare
più operations anziché chiamare
MutateAdGroupAds una volta per ogni
AdGroupAd. Per altri
esempi, consulta le nostre indicazioni sulle
operazioni batch.
Sebbene il raggruppamento delle richieste riduca il numero totale di chiamate API e mitighi i limiti di frequenza sulle richieste al minuto, potrebbe attivare il limite di frequenza delle operazioni al minuto se esegui un numero elevato di operazioni su un singolo account.
Limitazione e limitatori di frequenza
Oltre a limitare il numero totale di thread nella tua applicazione, puoi anche implementare limitatori di frequenza sul lato client. In questo modo, tutti i thread nei processi, nei cluster o in entrambi sono regolati da un limite di QPS specifico dal lato client.
Consulta il Guava RateLimiter o implementa il tuo algoritmo token bucket per un ambiente in cluster. Ad esempio, puoi gestire i token in un datastore in memoria distribuito a bassa latenza come Redis o Memcached, in cui ogni client acquisisce e utilizza un token prima di elaborare una richiesta. Se i token sono esauriti, il client attende che venga reintegrato il batch di token successivo.
Coda
Una coda di messaggi è la soluzione per la distribuzione del carico operativo, controllando al contempo le frequenze di richieste e consumer. Sono disponibili diverse opzioni di coda di messaggi, alcune open source, altre proprietarie, e molte di queste possono funzionare con lingue diverse.
Quando utilizzi le code di messaggi, puoi avere più producer che inviano messaggi alla coda e più consumer che elaborano questi messaggi. È possibile implementare le limitazioni sul lato consumer limitando il numero di consumer simultanei o implementando limitatori di frequenza o limitatori per i producer o i consumer.
Ad esempio, se un consumer di messaggi rileva un errore di limitazione di frequenza, può restituire la richiesta alla coda con un ritardo di ripetizione standardizzato (utilizzando il backoff esponenziale) e aggiornare un Feedback Loop del limitatore di frequenza condiviso in modo che tutti i consumer riducano automaticamente la frequenza di elaborazione durante il ripristino dall'errore.