L'API Google Play EMM ha un limite predefinito di 60.000 query al minuto per ogni EMM.
Se superi la quota, l'API EMM di Google Play restituisce HTTP 429 Too Many Requests.
Per assicurarti di non superare i limiti di utilizzo dichiarati e di offrire un'esperienza ottimale agli utenti, ti consigliamo di implementare alcune delle best practice descritte nella sezione di seguito.
Consigli per rimanere al di sotto dei limiti di utilizzo dell'API
Quando utilizzi l'API EMM di Google Play, puoi adottare alcune best practice per distribuire le richieste e ridurre il rischio di superare i limiti di utilizzo.
Intervallo casuale tra ore di inizio e intervalli
È probabile che attività come la sincronizzazione o il check-in dei dispositivi portino a un aumento significativo del volume di richieste. Invece di eseguire queste attività a intervalli regolari, puoi distribuire il carico delle richieste in modo casuale. Ad esempio, invece di sincronizzare ciascun dispositivo ogni 24 ore, puoi sincronizzarlo ogni 23 ore utilizzando un periodo di tempo scelto in modo casuale. Ciò contribuisce a distribuire il numero di richieste.
Analogamente, se esegui un job giornaliero che effettua molte chiamate API in rapida successione, ti consigliamo di avviarlo in modo casuale ogni giorno per evitare di effettuare un volume elevato di richieste per tutti i clienti aziendali contemporaneamente.
Utilizza il backoff esponenziale per riprovare le richieste
Se esegui job che includono molte chiamate API, utilizza una strategia di backoff esponenziale per raggiungere la quota. Il backoff esponenziale è un algoritmo che recupera le richieste in modo esponenziale. Un esempio di flusso per l'implementazione di un backoff esponenziale semplice è il seguente:
- Inviare una richiesta all'API Google Play EMM.
- Ricevi una risposta
HTTP 429. - Attendi 2 secondi +
random_time, quindi riprova la richiesta. - Ricevi una risposta
HTTP 429. - Attendi 4 secondi +
random_time, quindi riprova la richiesta. - Ricevi una risposta
HTTP 429. - Attendi 8 secondi +
random_time, quindi riprova la richiesta.
Generalmente random_time è un numero casuale che va da -0,5 * tempo di attesa
a +0,5 * tempo di attesa. Ridefinisci un nuovo random_time ogni volta che riprovi la tua richiesta. È possibile tentare una pianificazione più frequente delle chiamate API necessarie per completare le azioni rivolte agli utenti (ad esempio 0,5 s, 1 s e 2 s).
Processi batch con limitazione di frequenza
Ogni volta che un processo batch raggiunge la quota, la latenza delle azioni utente che chiamano l'API aumenta. In situazioni come queste, strategie quali il backoff esponenziale potrebbero non essere abbastanza efficaci nel mantenere una bassa latenza per le azioni degli utenti.
Per evitare di raggiungere ripetutamente i limiti di utilizzo dell'API e aumentare la latenza per le azioni rivolte all'utente, valuta la possibilità di utilizzare un limite di frequenza per i processi in batch (consulta la sezione RateLimiter di Google). Con un limitatore di frequenza puoi regolare la frequenza delle richieste API in modo da rimanere costantemente al di sotto dei limiti di utilizzo.
Ad esempio, avvia un processo in batch con una limitazione di frequenza predefinita di 50 QPS. Se l'API non restituisce un errore, aumenta lentamente il limite di frequenza (1% ogni minuto). Ogni volta che raggiungi la quota, riduci la percentuale di richiesta del 20%. Questo approccio adattivo determina una percentuale di richieste più ottimale, riducendo al contempo la latenza per le azioni rivolte agli utenti.