L'API EMM di Google Play ha un limite predefinito di 60.000 query al minuto per ogni EMM.
Se superi la quota, l'API Google Play EMM restituisce HTTP 429 Too Many Requests.
Per assicurarti di non superare i limiti di utilizzo indicati e offrire un'esperienza ottimale ai tuoi 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 Google Play EMM, puoi implementare alcune best practice per distribuire le richieste e ridurre il rischio di superare i limiti di utilizzo.
Generare orari di inizio e intervalli in modo casuale
È probabile che attività come la sincronizzazione o il check-in dei dispositivi contemporaneamente comportino un aumento significativo del volume di richieste. Anziché eseguire queste attività a intervalli regolarmente programmati, puoi distribuire il carico delle richieste randomizzando questi intervalli. Ad esempio, anziché sincronizzare ogni dispositivo ogni 24 ore, puoi sincronizzare ogni dispositivo in un periodo di tempo scelto in modo casuale compreso tra 23 e 25 ore. In questo modo, il numero di richieste viene distribuito.
Analogamente, se esegui un job giornaliero che effettua molte chiamate API in rapida successione, valuta la possibilità di avviare il job ogni giorno a un'ora casuale per evitare di fare un volume elevato di richieste per tutti i tuoi clienti aziendali contemporaneamente.
Utilizzare il backoff esponenziale per ripetere le richieste
Se esegui job costituiti da molte chiamate API, utilizza una strategia di backoff esponenziale in risposta al raggiungimento della quota. Il backoff esponenziale è un algoritmo che esegue un nuovo tentativo delle richieste in modo esponenziale. Un flusso di esempio per l'implementazione del backoff esponenziale semplice è il seguente:
- Invia una richiesta all'API EMM di Google Play.
- Ricevi una risposta
HTTP 429. - Attendi 2 secondi +
random_time, poi riprova. - Ricevere una risposta
HTTP 429. - Attendi 4 secondi +
random_time, quindi riprova a inviare la richiesta. - Ricevere una risposta
HTTP 429. - Attendi 8 secondi +
random_time, quindi riprova a inviare la richiesta.
random_time è in genere un numero casuale compreso tra -0,5 * tempo di attesa
e +0,5 * tempo di attesa. Ridefinisci un nuovo random_time ogni volta che riprovi la richiesta. Le chiamate API necessarie per completare le azioni rivolte agli utenti possono essere ripetute con una frequenza più elevata (ad es.0,5 secondi, 1 secondo e 2 secondi).
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 come il backoff esponenziale potrebbero non essere sufficientemente efficaci per mantenere una bassa latenza per le azioni utente.
Per evitare di raggiungere ripetutamente i limiti di utilizzo dell'API e aumentare la latenza per le azioni rivolte agli utenti, ti consigliamo di utilizzare un limitatore di velocità per le tue procedure collettive (vedi RateLimiter di Google). Con un limitatore di frequenza puoi modificare la frequenza delle richieste API in modo da rimanere costantemente al di sotto dei limiti di utilizzo.
Ad esempio, avvia un processo batch con un limite di frequenza predefinito di 50 QPS. Finché 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 richieste del 20%. Questo approccio adattivo consente di ottenere un tasso di richieste più ottimale, riducendo al contempo la latenza per le azioni rivolte agli utenti.