Limitazioni di frequenza
L'API Google Ads raggruppa le richieste per la limitazione di frequenza in base alle query al secondo (QPS) per ID cliente (CID) e token sviluppatore, il che significa che la misurazione viene applicata in modo indipendente sia ai CID sia ai token sviluppatore. L'API Google Ads utilizza un algoritmo Token Bucket per misurare le richieste e determinare un limite QPS appropriato, pertanto il limite esatto varia a seconda del carico complessivo del server in un determinato momento.
Lo scopo dell'imposizione di 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 verranno 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 Messaging, Redelivery e Throttling può aiutarti a creare un'app client più solida.
Di seguito sono riportate le pratiche consigliate ordinate in base alla complessità, con le strategie più semplici in alto e le architetture più solide ma sofisticate a seguire:
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 token sviluppatore.
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 aumentarlo per ottimizzare la velocità effettiva senza superare il limite di frequenza.
Inoltre, puoi prendere in considerazione la limitazione delle QPS dal lato client (consulta Limitazione e limitatori di frequenza).
Richieste batch
Valuta la possibilità di raggruppare più operazioni in un'unica richiesta. Questo è più applicabile alle chiamate MutateFoo. Ad esempio, se stai aggiornando lo stato di
più istanze di AdGroupAd, anziché
chiamare MutateAdGroupAds
una volta per ogni AdGroupAd, puoi chiamare
MutateAdGroupAds una volta e
passare più operations. Per altri esempi, consulta le nostre indicazioni sulle operazioni batch.
Sebbene il raggruppamento delle richieste riduca il numero totale di richieste e mitighi il limite di frequenza delle 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 nell'applicazione client, puoi anche implementare limitatori di frequenza sul lato client. In questo modo, tutti i thread nei processi e / o nei cluster sono regolati da un limite QPS specifico dal lato client.
Puoi consultare Guava Rate Limiter o implementare il tuo algoritmo basato su Token Bucket per un ambiente in cluster. Ad esempio, potresti generare token e memorizzarli in uno spazio di archiviazione transazionale condiviso, ad esempio un database, e ogni client dovrebbe acquisire e utilizzare un token prima di elaborare la richiesta. Se i token sono esauriti, il client dovrà attendere la generazione del batch di token successivo.
Coda
Una coda di messaggi è la soluzione per la distribuzione del carico operativo, oltre a controllare 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 li elaborano. È possibile implementare limitazioni sul lato consumer limitando il numero di consumer simultanei oppure implementare limitatori di frequenza o limitatori per i producer o i consumer.
Ad esempio, se un consumer di messaggi rileva un errore di limite di frequenza, può restituire la richiesta alla coda per riprovare. Allo stesso tempo, il consumer può anche notificare a tutti gli altri consumer di mettere in pausa l'elaborazione per un certo numero di secondi per ripristinare l'errore.