Limitazioni di frequenza

Le richieste di bucket dell'API Google Ads per la limitazione di frequenza in base a query al secondo (QPS) per ID cliente (CID) cliente e token sviluppatore, indicano che il monitoraggio viene applicato in modo indipendente sia sugli ID cliente sia sui token sviluppatore. L'API Google Ads utilizza un algoritmo bucket di token per misurare le richieste e determinare un limite QPS adeguato, 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 le QPS dal lato client.

Esistono diversi 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 al primo posto e architetture più solide ma sofisticate, dopo:

• Limitare le attività simultanee
• Raggruppamento delle richieste in batch
• Limitazione e limitazione della frequenza
• Codamento

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 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 eseguiranno richieste (in tutti i processi e le macchine) e aumentare la velocità per ottimizzare la velocità effettiva senza superare il limite di frequenza.

Inoltre, puoi prendere in considerazione la limitazione delle QPS dal lato client (consulta Throttling and Rate limiter).

Creazione di batch di richieste

Valuta la possibilità di raggruppare più operazioni in una singola richiesta. Questa opzione è più applicabile per le chiamate MutateFoo. Ad esempio, se stai aggiornando lo stato per più istanze di AdGroupAd, invece di chiamare MutateAdGroupAds una volta per ogni AdGroupAd, puoi chiamare MutateAdGroupAds una volta e passare in più istanze di operations. Per alcuni altri esempi, consulta le nostre linee guida sulle operazioni in batch.

Mentre le richieste in batch riducono il numero totale di richieste e mitigano il limite di frequenza delle richieste al minuto, potrebbe attivare il limite di frequenza delle operazioni al minuto se si eseguono molte operazioni su un singolo account.

Limitazione e limitazione della frequenza

Oltre a limitare il numero totale di thread nell'applicazione client, puoi anche implementare limiti di frequenza sul lato client. In questo modo, tutti i thread nei processi e / o nei cluster sono regolati da un limite di QPS specifico sul lato client.

Consulta il limitatore di frequenza Guava o implementa il tuo algoritmo basato su 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 ciascun client dovrebbe acquisire e utilizzare un token prima di elaborare la richiesta. Se i token sono stati utilizzati, il client dovrà attendere fino alla generazione del batch di token successivo.

Accodamento

Una coda di messaggi è la soluzione per la distribuzione del carico delle operazioni, controllando al contempo le tariffe delle richieste e dei consumer. Sono disponibili diverse opzioni per le code di messaggi, alcune open source, altre proprietarie, e molte possono funzionare con lingue diverse.

Quando utilizzi le code di messaggi, puoi fare in modo che più producer inviino messaggi alla coda e più consumer li elaborino. Le limitazioni possono essere implementate sul lato consumatore limitando il numero di consumatori simultanei o implementando limiti di frequenza o limitazioni per i produttori o per i consumatori.

Ad esempio, se un consumer di messaggi riscontra un errore di limitazione di frequenza, il consumer può restituire la richiesta alla coda per riprovare. Allo stesso tempo, questo consumer può anche comunicare a tutti gli altri consumer di mettere in pausa l'elaborazione per un certo numero di secondi per recuperare dall'errore.