Limity wykorzystania

Interfejs Google Play EMM API ma domyślny limit 60 tys. zapytań na minutę na każdego dostawcę usług EMM.

Jeśli przekroczysz limit, interfejs Google Play EMM API zwróci HTTP 429 Too Many Requests. Aby mieć pewność, że nie przekroczysz podanych limitów wykorzystania i zapewnisz użytkownikom optymalny komfort, rozważ zastosowanie niektórych sprawdzonych metod opisanych poniżej.

Zalecenia pozwalające utrzymywać się poniżej limitów wykorzystania interfejsu API

Jeśli używasz interfejsu Google Play EMM API, możesz stosować żądania, aby rozpowszechniać żądania i zmniejszyć ryzyko przekroczenia limitów wykorzystania.

Losowy czas rozpoczęcia i interwał

Działania takie jak synchronizowanie i rejestrowanie urządzeń w tym samym czasie prawdopodobnie spowodują znaczny wzrost liczby żądań. Zamiast wykonywać te zadania w regularnych odstępach czasu, możesz rozłożyć obciążenie żądania, losowo tworząc te interwały. Na przykład zamiast synchronizować każde urządzenie co 24 godziny, możesz je synchronizować w losowo wybranym przedziale czasu od 23 do 25 godzin. Dzięki temu możesz podzielić liczbę żądań.

I podobnie, jeśli każdego dnia uruchamiasz zadanie, które szybko wywołuje wiele interfejsów API, możesz uruchamiać je losowo, aby uniknąć wysyłania dużej liczby żądań do wszystkich klientów firmowych jednocześnie.

Aby ponowić próby, użyj wzrastającego czasu ponowienia

Jeśli uruchamiasz zadania, które składają się z wielu wywołań interfejsu API, użyj odpowiedzi wykładniczej ponowienia w odpowiedzi na osiągnięcie limitu. Wykładniczy czas do ponowienia to algorytm, który ponownie próbuje wysyłać żądania wykładniczo. Przykładowy proces wdrożenia prostej funkcji pogłębiania wykładniczego:

  1. Wyślij żądanie do interfejsu Google Play EMM API.
  2. Uzyskaj odpowiedź HTTP 429.
  3. Zaczekaj 2 sekundy i random_time, a następnie spróbuj jeszcze raz.
  4. Uzyskaj odpowiedź HTTP 429.
  5. Zaczekaj 4 sekundy i random_time, a potem spróbuj jeszcze raz.
  6. Uzyskaj odpowiedź HTTP 429.
  7. Poczekaj 8 sekund + random_time i spróbuj ponownie.

random_time jest zwykle losową liczbą od -0,5 * czas oczekiwania do +0,5 * czas oczekiwania. Definiuj nowy identyfikator random_time za każdym razem, gdy spróbujesz ponownie przesłać żądanie. Wywołania interfejsu API wymagane do wykonywania działań widocznych dla użytkowników można próbować częściej niż harmonogram (np.0,5 s, 1 s i 2 s).

Procesy wsadowe ograniczające liczbę żądań

Za każdym razem, gdy proces wsadowy osiągnie limit, opóźnienie działań użytkownika wywołujących interfejs API wzrasta. W takich sytuacjach strategie, takie jak wzrastający czas do ponowienia, mogą nie być wystarczająco skuteczne w utrzymaniu niewielkiego czasu oczekiwania na działania użytkownika.

Aby uniknąć wielokrotnych limitów wykorzystania interfejsu API i zwiększyć czas oczekiwania na działania dla użytkowników, rozważ zastosowanie ograniczenia liczby żądań w zadaniach wsadowych (patrz Google RateRateer). Za pomocą takiego limitu możesz dostosować częstotliwość żądań do interfejsu API w taki sposób, aby nie przekroczyć limitu wykorzystania.

Możesz na przykład rozpocząć proces wsadowy z domyślnym limitem liczby żądań na 50 kb/s. Dopóki interfejs API nie zwraca błędu, zwiększaj limit żądań stopniowo (1% co minutę). Za każdym razem, gdy osiągniesz limit, zmniejsz częstotliwość żądań o 20%. To adaptacyjne podejście zapewnia bardziej optymalną częstotliwość żądań i zmniejsza opóźnienie w przypadku działań dla użytkowników.