Interfejs Google Chat API jest usługą współdzieloną, dlatego stosujemy limity, aby mieć pewność, że wszyscy użytkownicy będą wykorzystywali go w uczciwy sposób, 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 limitu szybkości na zapleczu czatu mogą też generować tę samą odpowiedź z błędem. Jeśli wystąpi ten błąd, użyj wzrastającego algorytmu ograniczania szybkości i spróbuj ponownie później. O ile nie przekroczysz limitów na minutę podanych w poniższych tabelach, nie ma limitu liczby próśb, które możesz przesłać w ciągu dnia.
Do metod interfejsu Chat API stosuje się 2 typy limitów: limity na pokój i limity na projekt.
Limity na pokój
Limity przypadające na pokój ograniczają liczbę zapytań w danym pokoju i są wspólne dla wszystkich działających w nim aplikacji Google Chat, które wywołują wymienione metody interfejsu Chat API w przypadku poszczególnych limitów.
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ą liczbę zapytań dotyczących projektu Google Cloud, co ma zastosowanie do pojedynczej aplikacji Google Chat, która wywołuje określone metody interfejsu Chat API w przypadku 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) |
---|---|---|
Zapisywanie 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 |
Zapisy 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 zależnych od czasu (maksymalnie N żądań na X min) zalecamy, aby Twój kod wyłapywał ten wyjątek i korzystał z obciętego wykładniczego czasu do ponowienia, aby urządzenia nie wygenerowały nadmiernego obciążenia.
Wzrostowy czas do ponowienia to standardowa strategia obsługi błędów w przypadku aplikacji sieciowych. Algorytm Exponential back-off powtarza żądania, używając wykładniczo rosnących czasów oczekiwania między żądaniami, aż do maksymalnego czasu oczekiwania. Jeśli żądania nadal nie są skuteczne, ważne jest, aby opóźnienia między żądaniami zwiększały się z czasem, aż do momentu, gdy żądanie zostanie zrealizowane.
Przykładowy algorytm
Wykładniczy algorytm ponawiania prób wykładniczy ponawianie żądań, zwiększając czas oczekiwania między kolejnymi próbami do maksymalnego czasu do ponowienia. 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ą prześlij. - Jeśli żądanie się nie powiedzie, poczekaj 2 +
random_number_milliseconds
i spróbuj jeszcze raz. - 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. - Kontynuować oczekiwanie i próby do maksymalnej liczby prób, ale nie zwiększać czasu oczekiwania pomiędzy próbami.
gdzie:
- Czas oczekiwania wynosi
min(((2^n)+random_number_milliseconds), maximum_backoff)
, przy czym wartośćn
zwiększa się o 1 na każdą iterację (żądanie). random_number_milliseconds
to losowa liczba milisekund 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 ponownym przesłaniu żądania.maximum_backoff
wynosi zwykle 32 lub 64 sekund. Odpowiednia wartość zależy od przypadku użycia.
Klient może ponawiać próby po osiągnięciu maximum_backoff
czasu.
Ponowne próby po tym momencie 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 kolejnymi próbami i liczba ponownych prób 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ę zauważalnego wzrostu wykorzystania, możesz poprosić o korektę 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 wyższy limit