Limitazioni di frequenza

L'API Google Ads raggruppa le richieste per la limitazione della 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 varierà 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 ridurre i limiti di frequenza diminuendo 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 dei pattern di integrazione aziendale (EIP), come messaggistica, nuova consegna e limitazione, 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ù robuste ma sofisticate in basso:

• Limitare le attività simultanee
• Creazione di batch di richieste
• Limitazione e limitatori di velocità
• Inserimento in 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. 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 aumentare per ottimizzare la velocità effettiva senza superare il limite di frequenza.

Inoltre, puoi prendere in considerazione la limitazione delle 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 vale soprattutto per le chiamate al numero MutateFoo. Ad esempio, se stai aggiornando lo stato di più istanze di AdGroupAd, invece di 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 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 Token Bucket per un ambiente in cluster. Ad esempio, potresti generare token e archiviarli 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 deve attendere la generazione del batch successivo.

Coda

Una coda di messaggi è la soluzione per la distribuzione del carico di operazioni, controllando al contempo le tariffe di richiesta e dei consumatori. Sono disponibili diverse opzioni di code 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. I limiti di velocità possono essere implementati lato consumer limitando il numero di consumer simultanei oppure implementando limitatori di velocità o limitatori per i produttori o i consumer.

Ad esempio, se un consumer di messaggi rileva un errore di limite di frequenza, può restituire la richiesta alla coda per essere ritentata. Allo stesso tempo, il consumatore può anche notificare a tutti gli altri consumatori di mettere in pausa l'elaborazione per un numero di secondi per recuperare dall'errore.