Interfejs Google Chat API jest usługą współużytkowaną, dlatego stosujemy limity, aby mieć pewność, że wszyscy użytkownicy mogą z niego korzystać, a także aby chronić ogólną wydajność Google Workspace.
Jeśli przekroczysz limit, otrzymasz odpowiedź z kodem stanu HTTP 429: Too many requests
. Dodatkowe kontrole limitów liczby żądań w backendie Google Chat mogą też generować tę samą odpowiedź o błędzie. Jeśli tak się stanie, użyj algorytmu wykładniczego ponowienia i spróbuj ponownie później. Jeśli zmieścisz się w limitach na minutę wymienionych w poniższych tabelach, nie będzie ograniczeń co do liczby żądań, które możesz wysłać dziennie.
W przypadku metod interfejsu Chat API obowiązują 2 typy limitów: limity na pokój i projekty.
Limity na miejsce
Limity na pokój ograniczają liczbę zapytań w danym pokoju i są wspólne dla wszystkich aplikacji do obsługi czatu działających w tym pokoju, wywołujących wymienione metody interfejsu Chat API dla każdego limitu.
W tabeli poniżej znajdziesz szczegółowe informacje o limitach zapytań przypadających na pokój:
Limit na przestrzeń |
Metody interfejsu Chat API |
Limit (na 60 sekund, udostępniany |
---|---|---|
Odczyty na minutę |
|
900 |
Zapisy na minutę |
|
60 |
Limity na projekt
Limity na projekt ograniczają liczbę zapytań dotyczących projektu Google Cloud i mają zastosowanie do pojedynczej aplikacji do obsługi czatu, która wywołuje określone metody interfejsu Chat API w przypadku każdego limitu.
W tabeli poniżej znajdziesz szczegółowe informacje o limitach zapytań dotyczących poszczególnych projektów. Te limity znajdziesz też na stronie Limity.
Limit na projekt |
Metody interfejsu Chat API |
Limit (na 60 sekund) |
---|---|---|
Liczba zapisów wiadomości na minutę |
|
3000 |
Liczba odczytów wiadomości na minutę |
|
3000 |
Liczba zapisów subskrypcji na minutę |
|
300 |
Liczba odczytów subskrypcji na minutę |
|
3000 |
Liczba zapisów w przestrzeni na minutę |
|
60 |
Odczyty miejsca na minutę |
|
3000 |
Liczba zapisów załączników na minutę |
|
600 |
Liczba odczytów załączników na minutę |
|
3000 |
Liczba zapisów reakcji na minutę |
|
600 |
Odczyty reakcji na minutę |
|
3000 |
Dodatkowe limity wykorzystania
Obowiązują dodatkowe limity dotyczące tworzenia pokoi typu GROUP_CHAT
lub SPACE
(przy użyciu metody spaces.create
lub spaces.setup
).
Twórz mniej niż 35 przestrzeni na minutę i 210 przestrzeni na godzinę tego typu. Pokoje typu DIRECT_MESSAGE
nie podlegają tym dodatkowym limitom.
Duże zapytania na sekundę (QPS) kierowane na interfejsy API kierowane na tę samą przestrzeń mogą wywołać dodatkowe limity wewnętrzne, które nie są widoczne na stronie Limity.
Napraw błędy limitu czasu
W przypadku wszystkich błędów czasowych (maksymalnie N żądań na X minut) zalecamy, aby Twój kod wyłapał wyjątek i używał skróconego wykładniczego ponowienia, aby urządzenia nie wygenerowały nadmiernego obciążenia.
Ponawianie wykładnicze to standardowa strategia obsługi błędów w aplikacjach sieciowych. Algorytm wykładniczego ponowienia ponawia próbę wykonania żądań, wykorzystując wykładniczo wydłużające się czasy oczekiwania między żądaniami, aż do osiągnięcia maksymalnego czasu do ponowienia. Jeśli żądania wciąż nie są realizowane, ważne jest, aby opóźnienia między żądaniami wzrastały w miarę upływu czasu do momentu ich rozpatrzenia.
Przykładowy algorytm
Algorytm wykładniczego ponawiania powoduje wykładnicze ponawianie żądań, wydłużając czas oczekiwania między kolejnymi próbami aż do osiągnięcia maksymalnego czasu do ponowienia. Na przykład:
- Wyślij żądanie do interfejsu Google Chat API.
- Jeśli żądanie się nie powiedzie, poczekaj 1 +
random_number_milliseconds
i spróbuj ponownie. - Jeśli żądanie się nie powiedzie, poczekaj 2 +
random_number_milliseconds
i spróbuj ponownie. - Jeśli żądanie się nie powiedzie, poczekaj 4 +
random_number_milliseconds
i spróbuj ponownie. - I tak dalej, nawet do
maximum_backoff
raz. - Zaczekaj chwilę i ponów próbę, aż do osiągnięcia maksymalnej liczby ponownych prób, ale nie wydłużaj czasu oczekiwania między kolejnymi próbami.
gdzie:
- Czas oczekiwania wynosi
min(((2^n)+random_number_milliseconds), maximum_backoff)
, gdzie wartość w kolumnien
zwiększa się o 1 dla każdej iteracji (żądania). random_number_milliseconds
to losowa liczba milisekund,która jest mniejsza lub równa 1000. Pomaga to uniknąć przypadków, w których wiele klientów jest zsynchronizowanych w pewnej sytuacji i wszystkie są ponawiane jednocześnie, wysyłając żądania falami zsynchronizowanymi. Wartośćrandom_number_milliseconds
jest ponownie obliczana po każdym ponownym żądaniu.maximum_backoff
to zwykle 32 lub 64 sekundy. Odpowiednia wartość zależy od konkretnego przypadku użycia.
Klient może kontynuować ponawianie próby po osiągnięciu maximum_backoff
raza.
Ponowne próby po tym punkcie nie muszą wydłużać czasu do ponowienia. Jeśli na przykład klient używa czasu maximum_backoff
wynoszącego 64 sekundy, po osiągnięciu tej wartości może ponawiać próbę co 64 sekundy. W pewnym momencie klienty powinny utracić możliwość ponawiania próby w nieskończoność.
Czas oczekiwania między kolejnymi próbami a liczbą ponownych prób zależy od konkretnego przypadku użycia i warunków w sieci.
Poproś o zwiększenie limitu na projekt
W zależności od wykorzystania zasobów w projekcie możesz poprosić o zwiększenie limitu. Wywołania interfejsu API przez konto usługi są uznawane za korzystające z jednego konta. Prośba o zwiększenie limitu nie gwarantuje jego zatwierdzenia. Zatwierdzenie dużego zwiększenia limitu może potrwać dłużej.
Nie wszystkie projekty mają takie same limity. Z czasem będziesz korzystać z Google Cloud w miarę zwiększania limitów. Jeśli spodziewasz się znacznego wzrostu wykorzystania, możesz z wyprzedzeniem poprosić o korektę limitów na stronie Limity w konsoli Google Cloud.
Więcej informacji znajdziesz w tych materiałach:
- Prośby o zwiększenie limitu
- Wyświetlanie bieżącego wykorzystania limitów i limitów
- Wysyłanie prośby o zwiększenie limitu