Limitazioni di frequenza
L'API Google Ads raggruppa le richieste per il limite di frequenza in base alle query al secondo (QPS) per ID cliente (ID cliente) e token sviluppatore del cliente, il che significa che la misurazione viene applicata indipendentemente sia dagli ID cliente sia dai 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 varierà a seconda del carico sulla rete 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 assumere il controllo della tua app e ridurre i limiti di frequenza sia riducendo attivamente il numero di richieste sia limitando il QPS 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 messaggistica, reinvio e throttling, può aiutarti a creare un'app client più solida.
Le seguenti best practice consigliate sono ordinate in base alla complessità, con le strategie più semplici in alto e le architetture più robuste, ma sofisticate, in seguito:
Limita le attività simultanee
Una causa principale 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ò facilmente superare il limite di richieste al secondo a livello di token sviluppatore.
È consigliabile impostare un limite superiore ragionevole per il numero totale di attività simultanee che effettueranno richieste (in tutti i processi e le macchine) e modificarlo verso l'alto per ottimizzare il throughput senza superare il limite di frequenza.
Inoltre, puoi prendere in considerazione la limitazione del QPS lato client (consulta Limitazione e limitatori di frequenza).
Creazione di batch di richieste
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. Consulta le nostre linee guida sulle operazioni collettive per alcuni esempi aggiuntivi.
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.
Rallentamento e limiti di frequenza
Oltre a limitare il numero totale di thread nell'applicazione client, puoi anche implementare limitatori di frequenza lato client. In questo modo, puoi assicurarti che tutti i thread dei tuoi processi e / o cluster siano regolati da un limite QPS specifico lato client.
Puoi provare Guava Rate Limiter o implementare il tuo algoritmo basato su Token Bucket per un ambiente clusterizzato. Ad esempio, potresti generare token e memorizzarli in un'area di archiviazione transazionale condivisa come un database e ogni cliente dovrebbe acquisire e utilizzare un token prima di elaborare la richiesta. Se i token sono stati utilizzati, il cliente dovrà attendere fino a quando non verrà generato il successivo lotto di token.
Coda
Una coda di messaggi è la soluzione per la distribuzione del carico delle operazioni, nonché per il controllo delle frequenze di richieste e consumatori. Esistono diverse opzioni di code di messaggi, alcune open source e 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. I limiti possono essere implementati lato consumatore limitando il numero di consumatori simultanei oppure implementando limitatori di frequenza o throttle per i produttori o i consumatori.
Ad esempio, se un consumatore di messaggi riscontra un errore relativo al limite di tariffe, può restituire la richiesta alla coda per il nuovo tentativo. Allo stesso tempo, questo consumatore può anche notificare a tutti gli altri consumatori di mettere in pausa l'elaborazione per alcuni secondi per recuperare dall'errore.