Al momento stiamo eseguendo la migrazione di un sottoinsieme di tipi di report da report offline a report istantanei. Una volta eseguita la migrazione di un utente, le risposte di queries.list includeranno i report istantanei esistenti. Per ulteriori informazioni, leggi il post del nostro blog.
Le quote proteggono l'infrastruttura di Google dai processi automatizzati che utilizzano l'API Google Bid Manager in modo inappropriato. Assicurano che le azioni di uno sviluppatore non possano avere un impatto negativo sulla community più ampia.
Limiti di quota
I seguenti limiti di quota predefiniti sono condivisi da tutti i metodi e le risorse dell'API Bid Manager.
Nella Console API di Google questa quota è denominata Query al minuto per utente ed è impostata su 240.
Superamento dei limiti di quota
Nell'improbabile caso che la tua richiesta non vada a buon fine a causa del superamento di un limite di quota, l'API restituisce un codice di stato HTTP e il motivo dell'errore. Inoltre, il corpo della risposta contiene una descrizione dettagliata di ciò che ha causato l'errore. Per un esempio di risposta, consulta la guida sui messaggi di errore.
Il seguente elenco mostra i possibili errori e le azioni consigliate per gli errori delle richieste causati dal superamento dei limiti di quota.
Codice
Motivo
Messaggio
Azione consigliata
403
dailyLimitExceeded
Limite giornaliero superato
Non riprovare senza risolvere il problema. Esamina il tuo utilizzo dalla console API di Google e modifica il flusso di lavoro per effettuare meno richieste. Puoi richiedere una quota aggiuntiva se ritieni che il tuo utilizzo sia ragionevole.
403
userRateLimitExceeded
Limite di frequenza utenti superato
Riduci la frequenza con cui invii le richieste utilizzando il backoff esponenziale.
Che cos'è il backoff esponenziale?
Il backoff esponenziale è una strategia di gestione degli errori standard per le applicazioni di rete in cui il client riprova periodicamente a effettuare una richiesta non riuscita per un periodo di tempo crescente. Se un volume elevato di richieste o un traffico di rete intenso fa sì che il server restituisca errori, il backoff esponenziale può essere una buona strategia per la gestione di questi errori. Al contrario, non si tratta di una strategia pertinente per la gestione di errori non correlati al volume di rete o ai tempi di risposta, come credenziali di autorizzazione non valide o errori di file non trovato.
Se usato correttamente, il backoff esponenziale aumenta l'efficienza dell'utilizzo della larghezza di banda, riduce il numero di richieste necessarie per ottenere una risposta corretta e massimizza la velocità effettiva delle richieste in ambienti contemporanei.
Il flusso per l'implementazione di un backoff esponenziale semplice è il seguente:
Effettua una richiesta all'API.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 1 secondo + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 2 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 4 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 8 secondi + numero_casuale_di_millisecondi e riprova.
Ricevi una risposta HTTP 503, che indica che devi ritentare la richiesta.
Attendi 16 secondi + numero_casuale_di_millisecondi e riprova.
Interrompi. Segnala o registra un errore.
Nel flusso precedente, numero_casuale_millisecondi è un numero casuale di millisecondi inferiore o uguale a 1000. Questa operazione è necessaria, poiché l'introduzione di un piccolo ritardo casuale consente di distribuire il carico in modo più uniforme ed evitare la possibilità di stampare in eccesso il server. Il valore di numero_casuale_millisecondi deve essere ridefinito dopo ogni attesa.
Nota : l'attesa è sempre (2 ^ n) + numero_casuale_millisecondi, dove n è un numero intero con aumento monotonico inizialmente definito come 0. Il numero intero n viene incrementato di 1 per ogni iterazione (ogni richiesta).
L'algoritmo è impostato per terminare quando n è 5. Questo limite impedisce ai client di effettuare nuovi tentativi all'infinito e genera un ritardo totale di circa 32 secondi prima che una richiesta venga considerata "un errore irreversibile". Un numero massimo di nuovi tentativi è sufficiente, soprattutto se è in corso un caricamento lungo; assicurati solo di limitare il ritardo tra tentativi a un valore ragionevole, ad esempio inferiore a un minuto.
Richiesta di quota giornaliera aggiuntiva
Se ritieni che la tua applicazione richieda una quota giornaliera aggiuntiva, puoi richiederne una maggiore seguendo le istruzioni riportate di seguito.
Le istruzioni seguenti si applicano solo ai progetti che hanno riscontrato un errore dailyLimitExceeded. Le azioni consigliate per altri errori di quota sono illustrate nella tabella precedente.
Esamina le statistiche sull'utilizzo dalla pagina Metriche per verificare che l'applicazione funzioni come previsto. Prima di procedere, presta molta attenzione ai metodi chiamati e affronta eventuali utilizzi imprevisti o eccessivi.
Se l'utilizzo sembra normale, vai alla pagina Quote, fai clic sull'icona di modifica accanto a Query giornaliere e poi sul link "Richiedi una quota più alta".
Assicurati di esaminare le informazioni e di seguire le istruzioni incluse nel modulo di richiesta della quota prima di inviare una richiesta di aumento.
