Interfejs Google Chat API jest usługą współdzieloną, dlatego stosujemy limity i ograniczenia, aby zapewnić sprawiedliwe korzystanie z niego przez wszystkich użytkowników oraz chronić ogólną wydajność Google Workspace.
Jeśli przekroczysz limit, otrzymasz odpowiedź z kodem stanu HTTP 429: Too many requests
. Dodatkowe kontrole limitu szybkości na zapleczu czatu mogą też generować tę samą odpowiedź o błędzie. Jeśli wystąpi ten błąd, użyj wzrastającego algorytmu ograniczania szybkości i spróbuj ponownie później. Dopóki nie przekroczysz limitów na minutę podanych w poniższych tabelach, nie będziesz mieć limitu liczby próśb na dzień.
Do metod interfejsu Chat API stosuje się 2 typy limitów: limity na pokój i limity na projekt.
Limity na pokój
Limity na pokój ograniczają częstotliwość zapytań w danym pokoju i są udostępniane wszystkim aplikacjom na czacie działającym w tym pokoju, które wywołują wymienione metody interfejsu API czatu dla każdego limitu.
Tabela poniżej zawiera limity zapytań na konto:
Limit na pokój |
Metody interfejsu API czatu |
Limit (na 60 sekund, udostępniany |
---|---|---|
Odczyty na minutę |
|
900 |
Pisanie na minutę |
|
60 |
Limity według projektu
Limity na projekt ograniczają częstotliwość zapytań do projektu Google Cloud i w ten sposób mają zastosowanie do pojedynczej aplikacji Google Chat wywołującej określone metody interfejsu Chat API dla każdego limitu.
W tabeli poniżej znajdziesz limity zapytań na projekt. Te limity znajdziesz też na stronie Limity.
Limit na projekt |
Metody interfejsu API czatu |
Limit (na 60 sekund) |
---|---|---|
Liczba zapisów wiadomości na minutę |
|
3000 |
Liczba odczytań wiadomości na minutę |
|
3000 |
Liczba zapisów członkostwa na minutę |
|
300 |
Liczba odsłuchań treści z subskrypcji na minutę |
|
3000 |
Liczba zapisów w pokoju na minutę |
|
60 |
Liczba odczytów w przestrzeni 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 |
Liczba odczytów reakcji na minutę |
|
3000 |
Dodatkowe limity wykorzystania
Istnieją dodatkowe limity dotyczące tworzenia pokoi typu GROUP_CHAT
lub SPACE
(za pomocą metody spaces.create
lub spaces.setup
).
Utwórz mniej niż 35 pokoi na minutę i 800 pokoi na godzinę tego typu. Pomieszczenia typu DIRECT_MESSAGE
nie podlegają tym dodatkowym limitom.
Wysoki ruch z interfejsu API kierowany na ten sam obszar może powodować dodatkowe limity wewnętrzne, które nie są widoczne na stronie Limity.
Rozwiązywanie błędów związanych z limitem czasowym
W przypadku wszystkich błędów związanych z czasem (maksymalnie N żądań na X minut) zalecamy, aby kod przechwytywał wyjątki i używał odciętej ujemnej funkcji wykładniczej, aby urządzenia nie generowały nadmiernego obciążenia.
Wzrostowy czas do ponowienia to standardowa strategia obsługi błędów w przypadku aplikacji sieciowych. Algorytm wzrastającego czasu do ponowienia powtarza żądania, zwiększając wykładniczo czas oczekiwania między żądaniami do maksymalnego czasu do ponowienia. Jeśli żądania nadal nie działają, ważne jest, aby opóźnienia między żądaniami zwiększały się z czasem, aż żądanie zostanie zrealizowane.
Przykładowy algorytm
Algorytm Exponential back-off powtarza żądania wykładniczo, zwiększając czas oczekiwania między próbami do maksymalnego czasu oczekiwania. Na przykład:
- Wyślij żądanie do interfejsu Google Chat API.
- Jeśli prośba się nie powiedzie, odczekaj 1 +
random_number_milliseconds
i ponownie ją wyślij. - Jeśli prośba nie powiedzie się, odczekaj 2 +
random_number_milliseconds
i spróbuj ponownie. - Jeśli prośba zakończy się niepowodzeniem, odczekaj 4 +
random_number_milliseconds
i ponownie ją wyślij. - I tak dalej, aż do
maximum_backoff
razy. - Kontynuuj oczekiwanie i próby do maksymalnej liczby prób, ale nie wydłużaj czasu oczekiwania pomiędzy próbami.
gdzie:
- Czas oczekiwania wynosi
min(((2^n)+random_number_milliseconds), maximum_backoff)
, a wartośćn
zwiększa się o 1 przy każdej iteracji (żądaniu). random_number_milliseconds
to losowa liczba w milisekundach mniejsza lub równa 1000. Pomaga to uniknąć sytuacji, w której wiele klientów jest synchronizowanych w jakiejś sytuacji i wszystkie próbują ponownie od razu, wysyłając żądania w zsynchronizowanych falach. Wartośćrandom_number_milliseconds
jest ponownie obliczana po każdym żądaniu ponownego próby.maximum_backoff
wynosi zwykle 32 lub 64 sekund. Odpowiednia wartość zależy od przypadku użycia.
Klient może kontynuować próby po upływie czasu maximum_backoff
.
Ponowne próby po tym punkcie nie muszą zwiększać czasu oczekiwania. Jeśli na przykład klient używa wartości maximum_backoff
wynoszącej 64 sekundy, po osiągnięciu tej wartości może próbować ponownie co 64 sekundy. W pewnym momencie należy zablokować klientom możliwość nieograniczonego powtarzania prób.
Czas oczekiwania między próbami i ich liczba zależą od przypadku użycia i warunkó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 korzystanie z jednego konta. Wysłanie wniosku 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. W miarę zwiększania się wykorzystania Google Cloud może być konieczne zwiększenie limitów. Jeśli spodziewasz się znacznego wzrostu wykorzystania, możesz poprosić o zmianę limitów na stronie Limity w konsoli Google Cloud.
Więcej informacji znajdziesz w tych materiałach:
- Informacje o prośbach o zwiększenie limitu
- Wyświetlanie bieżącego wykorzystania limitu i limitów
- Wysyłanie prośby o zwiększenie limitu