Limitazioni di frequenza

Le richieste dei bucket dell'API Google Ads per la limitazione della frequenza in base alle query al secondo (QPS) per ID cliente client (ID cliente) e token sviluppatore, il che significa che il monitoraggio viene applicato in modo indipendente sia sui CID che sui token sviluppatore. L'API Google Ads utilizza un algoritmo bucket di token 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 è evitare che un utente interrompa il servizio per altri utenti sovraccaricando (intenzionalmente o involontariamente) 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 mitigare i limiti di frequenza riducendo attivamente il numero di richieste e limitando il QPS dal lato client.

Esistono vari modi per ridurre le probabilità di superare il limite di frequenza. Acquisire familiarità con i concetti dei modelli di integrazione aziendale (EIP), come messaggistica, ripubblicazione e limitazione, può aiutarti a creare un'app client più solida.

Le seguenti pratiche consigliate ordinate per complessità, con strategie più semplici nella parte superiore e architetture più solide ma sofisticate in seguito:

• Limitare le attività simultanee
• Richieste di raggruppamento
• Limitazioni e limitazioni di frequenza
• Coda

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. Anche se non limitiamo il numero di richieste in parallelo che un'app client può avere, questo può facilmente 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 effettuano richieste (in tutti i processi e le macchine) e di modificarlo per ottimizzare la velocità effettiva senza superare il limite di frequenza.

Inoltre, puoi valutare la possibilità di limitare il QPS dal lato client (consulta la pagina relativa a limitazioni e limitazione di frequenza).

Creazione di batch di richieste

Valuta la possibilità di raggruppare più operazioni in un'unica richiesta. Questo è il caso più applicabile alle chiamate MutateFoo. Ad esempio, se aggiorni lo stato di più istanze di AdGroupAd, anziché chiamare MutateAdGroupAds una volta per ogni AdGroupAd, puoi chiamare MutateAdGroupAds una volta e passare più di operations. Consulta le nostre linee guida per le operazioni in batch per alcuni esempi aggiuntivi.

Anche se le richieste in batch riducono il numero totale di richieste e attenuano il limite di frequenza di richieste al minuto, potrebbe attivare il limite di frequenza di operazioni al minuto se esegui un numero elevato di operazioni su un singolo account.

Limitazione e limitazione di frequenza

Oltre a limitare il numero totale di thread nell'applicazione client, puoi anche implementare i limiti di frequenza sul lato client. Ciò garantisce che tutti i thread dei tuoi processi e / o cluster siano regolati da un limite QPS specifico dal lato client.

Puoi controllare Guava Rate Limiter o implementare il tuo algoritmo basato sul tuo bucket di token per un ambiente in cluster. Ad esempio, potresti generare token e archiviarli in uno spazio di archiviazione transazionale condiviso come un database, e ogni client deve acquisire e utilizzare un token prima di elaborare la richiesta. Se i token sono stati esauriti, il client deve attendere che venga generato il batch successivo.

Aggiunta alla coda

Una coda di messaggi è la soluzione per la distribuzione del carico delle operazioni e per il controllo delle tariffe delle richieste e dei consumer. Sono disponibili diverse opzioni per le code di messaggi, alcune open source, alcune proprietarie, e molte di esse possono essere utilizzate in lingue diverse.

Quando utilizzi le code di messaggi, puoi avere più producer che eseguono il push dei messaggi alla coda e più consumer che li elaborano. Le limitazioni possono essere implementate sul lato consumatore limitando il numero di consumatori simultanei, oppure possono implementare limitazioni di frequenza o limitazioni per i produttori o i consumatori.

Ad esempio, se un consumer dei messaggi riscontra un errore relativo al limite di tariffe, può restituire la richiesta alla coda per riprovare. Allo stesso tempo, il consumatore può anche chiedere a tutti gli altri consumatori di mettere in pausa l'elaborazione per un certo numero di secondi per ripristinare l'errore.