Poiché l'API Google Chat è un servizio condiviso, applichiamo quote e limitazioni per garantire che venga utilizzata in modo equo da tutti gli utenti e per proteggere le prestazioni generali di Google Workspace.
Se superi una quota, riceverai una risposta con codice di stato HTTP 429: Too many requests. Anche altri controlli del limite di frequenza nel backend di Chat potrebbero generare la stessa risposta di errore. Se si verifica questo errore, devi utilizzare un algoritmo di backoff esponenziale e riprovare più tardi. Se rispetti le quote per minuto elencate nelle seguenti tabelle, non c'è limite al numero di richieste che puoi effettuare al giorno.
Ai metodi dell'API Chat si applicano due tipi di quote: per spazio e per progetto.
Quote per spazio
Le quote per spazio limitano la frequenza delle query in un determinato spazio e sono condivise tra tutte le app Chat che agiscono in questo spazio e chiamano i metodi dell'API Chat elencati per ogni quota.
La seguente tabella mostra in dettaglio i limiti di query per spazio:
Quota per spazio |
Metodi dell'API Chat |
Limite (per 60 secondi, condiviso |
|---|---|---|
Letture al minuto |
|
900 |
Scritture al minuto |
|
60 |
Quote per progetto
Le quote per progetto limitano la frequenza di query per un progetto Google Cloud e si applicano a una singola app di Chat che chiama i metodi dell'API Chat specificati per ogni quota.
La tabella seguente illustra i limiti di query per progetto. Puoi trovare questi limiti anche nella pagina Quote.
Quota per progetto |
Metodi dell'API Chat |
Limite (ogni 60 secondi) |
|---|---|---|
Scritture di messaggi al minuto |
|
3000 |
Letture di messaggi al minuto |
|
3000 |
Scritture di adesioni al minuto |
|
300 |
Letture di adesioni al minuto |
|
3000 |
Scritture nello spazio al minuto |
|
60 |
Letture dello spazio al minuto |
|
3000 |
Scritture allegati al minuto |
|
600 |
Letture di allegati al minuto |
|
3000 |
Scritture reazioni al minuto |
|
600 |
Letture di reazioni al minuto |
|
3000 |
Ulteriori limiti di utilizzo
Esistono limiti di quota aggiuntivi per la creazione di spazi di tipo GROUP_CHAT
o SPACE (utilizzando il metodo spaces.create o spaces.setup).
Creare meno di 35 spazi al minuto e 800 spazi all'ora di questi tipi. Gli spazi di tipo DIRECT_MESSAGE non sono soggetti a questi
limiti di quota aggiuntivi.
Un traffico API elevato che ha come target lo stesso spazio può attivare ulteriori limiti interni non visibili nella pagina Quote.
Risolvere gli errori di quota basati sul tempo
Per tutti gli errori basati sul tempo (massimo N richieste ogni X minuti), ti consigliamo che il tuo codice rilevi l'eccezione e utilizzi un backoff esponenziale troncato per assicurarti che i dispositivi non generino un carico eccessivo.
Il backoff esponenziale è una strategia di gestione degli errori standard per le applicazioni di rete. Un algoritmo di backoff esponenziale riprova le richieste utilizzando tempi di attesa in aumento esponenziale tra una richiesta e l'altra, fino a un tempo di backoff massimo. Se le richieste continuano a non andare a buon fine, è importante che i ritardi tra le richieste aumentino nel tempo fino a quando la richiesta non va a buon fine.
Algoritmo di esempio
Un algoritmo con backoff esponenziale riprova le richieste in modo esponenziale, aumentando il tempo di attesa tra un nuovo tentativo e l'altro fino al tempo di backoff massimo. Ad esempio:
- Invia una richiesta all'API Google Chat.
- Se la richiesta non va a buon fine, attendi 1 +
random_number_millisecondse riprova. - Se la richiesta non va a buon fine, attendi 2 +
random_number_millisecondse riprova. - Se la richiesta non va a buon fine, attendi 4 +
random_number_millisecondse riprova. - E così via, fino a un
maximum_backoffvolta. - Continua ad attendere e a riprovare fino al numero massimo di nuovi tentativi, ma non aumentare il periodo di attesa tra un nuovo tentativo e l'altro.
dove:
- Il tempo di attesa è
min(((2^n)+random_number_milliseconds), maximum_backoff), connincrementato di 1 per ogni iterazione (richiesta). random_number_millisecondsè un numero casuale di millisecondi inferiore o uguale a 1000. In questo modo si evitano i casi in cui molti client vengono sincronizzati da qualche situazione e tutti riprovano contemporaneamente, inviando richieste in ondate sincronizzate. Il valore dirandom_number_millisecondsviene ricalcolato dopo ogni richiesta di nuovo tentativo.maximum_backoffin genere dura 32 o 64 secondi. Il valore appropriato dipende dal caso d'uso.
Il client può continuare a riprovare dopo aver raggiunto il tempo maximum_backoff.
I tentativi successivi a questo punto non devono continuare ad aumentare il tempo di backoff. Ad
esempio, se un client utilizza un tempo maximum_backoff di 64 secondi, dopo aver raggiunto questo valore, potrà riprovare ogni 64 secondi. A un certo punto, ai client dovrebbe essere impedito di riprovare a tempo indeterminato.
Il tempo di attesa tra i nuovi tentativi e il numero di nuovi tentativi dipendono dal caso d'uso e dalle condizioni di rete.
Richiedere un aumento della quota per progetto
A seconda dell'utilizzo delle risorse del progetto, potresti voler richiedere un aumento della quota. Le chiamate API da parte di un account di servizio sono considerate come se utilizzassero un singolo account. La richiesta di aumentare una quota non ne garantisce l'approvazione. L'approvazione può richiedere più tempo nel caso di un aumento consistente della quota.
Non tutti i progetti hanno le stesse quote. Man mano che utilizzi sempre più Google Cloud nel tempo, le tue quote potrebbero dover aumentare. Se prevedi un aumento imminente e consistente dell'utilizzo, puoi richiedere un adeguamento della quota in modo proattivo nella pagina Quote della console Google Cloud.
Per saperne di più, consulta le seguenti risorse:
- Informazioni sulle richieste di aumento della quota
- Visualizzare l'utilizzo e i limiti delle quote attuali
- Richiedere un limite di quota più elevato