Interfejs Google Vault API jest usługą współdzieloną, więc stosujemy limity, aby zapewnić sprawiedliwe korzystanie z niego przez wszystkich użytkowników oraz chronić ogólny stan systemu Google Workspace.
Limity dotyczące produktów
W organizacji nie można przeprowadzać więcej niż 20 eksportów naraz.
Limity żądań do interfejsu API
Każda organizacja może mieć do 600 odczytów spraw na minutę dla wszystkich projektów i użytkowników, w tym żądań przesyłanych przez Vault API i na vault.google.com.
W tabelach poniżej znajdziesz limity liczby żądań przypadających na minutę na projekt:
Liczba żądań odczytu na minutę na projekt | |
---|---|
Eksportowanie, sprawa i zapisane zapytanie | 120 |
Zawieś | 228 |
Długo trwająca operacja | 300 |
Liczba żądań zapisu na minutę na projekt | |
---|---|
Eksportuj | 20 |
Zawieś | 60 |
Uprawnienia sprawy | 30 |
Matter | 60 |
Zapisane zapytanie | 45 |
Liczba żądań wyszukiwania na minutę na projekt | |
---|---|
Liczba wyszukiwań | 20 |
Wykorzystanie limitu według metody
Limit używany przez żądanie zależy od wywołanej metody. Poniższa tabela przedstawia wykorzystanie limitu na metodę:
Metoda | Koszty limitów |
---|---|
matters.close matters.create matters.delete matters.reopen matters.update matters.undelete
|
1 przeczytana sprawa 1 zapisana sprawa |
matters.count |
1 liczba |
matters.get |
Przeczytano 1 sprawę |
matters.list |
10 odczytów sprawy |
matters.addPermissions matters.removePermissions
|
1 odczyt sprawy 1 zapis sprawy 1 uprawnienia do zapisu |
matters.exports.create |
1 odczyt eksportu 10 zapisów eksportu |
matters.exports.delete |
1 zapisanie eksportu |
matters.exports.get |
1 odczyt eksportu |
matters.exports.list |
5 odczytów eksportu |
matters.holds.addHeldAccounts matters.holds.create matters.holds.delete matters.holds.removeHeldAccounts matters.holds.update
|
1 przeczytana sprawa 1 zapisanie sprawy 1 blokada odczytana 1 blokada (zapis) |
matters.holds.list |
1 przeczytana sprawa 3 odczyty blokady |
matters.holds.accounts.create matters.holds.accounts.delete matters.holds.accounts.list
|
1 przeczytana sprawa 1 zapisanie sprawy 1 blokada odczytana 1 blokada (zapis) |
matters.savedQueries.create matters.savedQueries.delete
|
1 przeczytana sprawa 1 zapisana sprawa 1 zapisane zapytanie odczytane 1 zapisane zapytanie zapisane |
matters.savedQueries.get |
1 przeczytana sprawa Odczytano 1 zapisane zapytanie |
matters.savedQueries.list |
1 przeczytana sprawa 3 odczyty zapisanego zapytania |
operations.get |
Odczytano 1 długo trwającą operację |
Napraw błędy limitu ograniczonego czasowo
Jeśli przekroczysz limit na minutę lub na organizację, zwykle otrzymasz odpowiedź z kodem stanu HTTP 429: Too many requests
.
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 powodowały nadmiernego obciążenia.
Wykładniczy czas ponowienia to standardowa strategia obsługi błędów w aplikacjach sieciowych. Algorytm wykładniczy ponawiania prób ponawiania żądań, w wyniku których rośnie wykładniczo czas oczekiwania między żądaniami aż do 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 zrealizowania.
Przykładowy algorytm
Algorytm wykładniczy ponawiania prób wykładniczych, 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 Vault API.
- Jeśli żądanie się nie powiedzie, zaczekaj 1
random_number_milliseconds
i spróbuj jeszcze raz. - Jeśli żądanie się nie powiedzie, zaczekaj 2
random_number_milliseconds
i spróbuj jeszcze raz. - Jeśli żądanie się nie powiedzie, poczekaj 4
random_number_milliseconds
i spróbuj jeszcze raz. - I tak dalej, do
maximum_backoff
raz. - Zaczekaj i ponów próbę, maksymalnie do 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)
, przy czymn
dla każdej iteracji (żądania) zwiększa się o 1. random_number_milliseconds
to losowa liczba milisekund,mniejsza lub równa 1000. Pomaga to uniknąć sytuacji, w której wielu klientów jest synchronizowanych w określonej sytuacji i wszystkie ponawiają próby jednocześnie, wysyłając żądania w zsynchronizowanych falach. Wartośćrandom_number_milliseconds
jest przeliczana po każdym ponownym żądaniu.maximum_backoff
to zwykle 32 lub 64 sekundy. Odpowiednia wartość zależy od przypadku użycia.
Klient może kontynuować ponawianie próby po osiągnięciu limitu maximum_backoff
.
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, to po osiągnięciu tej wartości klient może ponawiać próbę co 64 sekundy. W pewnym momencie klienty powinny utracić możliwość ponawiania prób 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 sieci.
Poproś o zwiększenie limitu
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. Zgłoszenie do programu o zwiększonym limicie 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ę jak z czasem będziesz korzystać z Google Cloud, Twoje limity mogą wymagać zwiększenia. Jeśli spodziewasz się znacznego wzrostu wykorzystania, możesz aktywnie 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 limitu i związanych z nim limitów
- Wysyłanie prośby o zwiększenie limitu
Ceny
Użytkownicy Google Workspace mogą korzystać z interfejsu Google Vault API bez dodatkowych opłat.