Interfejs Google Chat API jest usługą współdzieloną, dlatego stosujemy limity aby zapewnić, że wszyscy użytkownicy będą z niej uczciwie korzystać, i wydajność Google Workspace.
Jeśli przekroczysz limit, otrzymasz żądanie HTTP 429: Too many requests
w odpowiedzi na kod stanu. Dodatkowe sprawdzanie limitu liczby żądań w Google Chat
backend może również wygenerować tę samą odpowiedź na żądanie błędu. Jeśli wystąpi ten błąd,
należy użyć parametru
algorytm wykładniczego ponowienia
i spróbuj ponownie później. Dopóki nie przekroczysz limitów na minutę podanych w
podanych niżej tabel, nie ma ograniczeń co do liczby żądań, które możesz przesłać:
dziennie.
W przypadku metod interfejsu Chat API obowiązują 2 typy limitów: na pokój i na projekt limity.
Limity na pokój
Limity na miejsce ograniczają liczbę zapytań w danym miejscu i są współdzielone przez wszystkich aplikacji do obsługi czatu działających w tym pokoju, które wywołują listę Metody interfejsu Chat API w przypadku poszczególnych limitów.
W tabeli poniżej znajdują się szczegółowe informacje na temat limitów zapytań dotyczących pokoju:
Limit na miejsce |
Metody interfejsu Chat API |
Limit (na 60 sekund, udostępniany |
---|---|---|
Czytania na minutę |
|
900 |
Zapisy na minutę |
|
60 |
Limity na projekt
limity na projekt ograniczają liczbę zapytań dotyczących projektu Google Cloud; więc dotyczy jednej aplikacji Google Chat wywołującej określony Metody interfejsu Chat API w przypadku poszczególnych limitów.
W tabeli poniżej znajdziesz informacje o limitach zapytań dotyczących projektów. Możesz też znaleźć te limity znajdziesz 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 |
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 |
Zapisy 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
albo spaces.setup
).
Twórz mniej niż 35 spacji na minutę i 210 spacji na minutę
godzin pracy tego typu. Pokoje typu DIRECT_MESSAGE
nie podlegają tym zasadom
dodatkowych limitów.
Mogą aktywować się duże zapytania na sekundę dla dowolnego interfejsu API kierowanego na tę samą przestrzeń dodatkowe limity wewnętrzne, które nie są widoczne Limity.
Rozwiązywanie błędów limitów czasowych
W przypadku wszystkich błędów zależnych od czasu (maksymalnie N żądań na X min) zalecamy kod przechwytuje ten wyjątek i używa obciętego wykładniczego czasu do ponowienia, aby zapewnić urządzenia nie generują nadmiernego obciążenia.
Wykładniczy czas do ponowienia to standardowa strategia obsługi błędów w aplikacjach sieciowych. An algorytm wykładniczego ponowienia ponawia próby żądania, wykorzystując wykładniczo wydłużające się czasy oczekiwania między żądaniami aż do maksymalnego czasu ponowienia. Jeśli żądania nadal nie zostaną zrealizowane, ważne, że opóźnienia między prośbami zwiększają się z czasem do momentu, gdy żądanie zostanie rozpatrzone pozytywnie.
Przykładowy algorytm
Wykładniczy algorytm do ponawiania próbuje wykładniczo ponawiać próby, zwiększając czas oczekiwania między ponownymi próbami aż do maksymalnego czasu 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 do danej prośby. - Jeśli żądanie się nie powiedzie, poczekaj 2 +
random_number_milliseconds
i spróbuj ponownie do danej prośby. - Jeśli żądanie się nie powiedzie, poczekaj 4 +
random_number_milliseconds
i spróbuj ponownie do danej prośby. - I tak dalej, maksymalnie
maximum_backoff
raz. - Zaczekaj i ponawiaj próby aż do określonej maksymalnej liczby 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)
, z wartościąn
przyrostową o 1 dla każdej iteracji (żądania). random_number_milliseconds
jest losową liczbą milisekund mniejszą niż lub równy 1000. Pozwala to uniknąć przypadków, w których wiele klientów jest zsynchronizowanych przez w jakiejś sytuacji i spróbuje ponownie jednocześnie wysyłać żądania fale. Wartość funkcjirandom_number_milliseconds
jest obliczana ponownie po każdej spróbuj jeszcze raz.maximum_backoff
zwykle trwa 32 lub 64 sekundy. 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 punkcie nie muszą przez cały czas wydłużać czasu do ponowienia. Dla:
np. jeśli klient używa czasu maximum_backoff
wynoszącego 64 sekundy, a następnie po osiągnięciu
tę wartość, klient może ponawiać próby co 64 sekundy. W pewnym momencie
nie powinno się uniemożliwić ponawianiu prób w nieskończoność.
Czas oczekiwania między ponownymi próbami a liczba ponownych prób zależy od konkretnego przypadku użycia i stanu sieci.
Poproś o zwiększenie limitu na projekt
W zależności od wykorzystania zasobów projektu możesz poprosić o zwiększenie limitu wzrost. Uznaje się, że wywołania interfejsu API przez konto usługi korzystają z metody jedno konto. Zgłoszenie prośby o zwiększenie limitu nie gwarantuje jego zatwierdzenia. Duże Zatwierdzenie zwiększenia limitu może potrwać dłużej.
Nie wszystkie projekty mają takie same limity. Ponieważ coraz częściej korzystasz z Google Cloud w ramach limity czasu mogą wymagać zwiększenia limitu. Jeśli spodziewasz się w nadchodzącym okresie wzrost wykorzystania, możesz proaktywnie poproś o korektę limitu 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 limitu i limitów
- Wysyłanie prośby o zwiększenie limitu