Límites de uso

La API de EMM de Google Play tiene un límite predeterminado de 60,000 consultas por minuto para cada EMM.

Si excedes la cuota, la API de EMM de Google Play muestra HTTP 429 Too Many Requests. Para asegurarte de no exceder los límites de uso establecidos y ofrecer una experiencia óptima a los usuarios, considera implementar algunas de las prácticas recomendadas que se describen en la siguiente sección.

Recomendaciones para mantenerte por debajo de los límites de uso de la API

Cuando usas la API de EMM de Google Play, hay algunas prácticas recomendadas que puedes implementar para distribuir solicitudes y reducir el riesgo de exceder los límites de uso.

Intervalos y horas de inicio aleatorios

Es posible que actividades como sincronizar o registrar dispositivos al mismo tiempo generen un aumento significativo en el volumen de solicitudes. En lugar de realizar estas actividades en intervalos programados con regularidad, puedes distribuir tu carga de solicitudes mediante la aleatorización de estos intervalos. Por ejemplo, en lugar de sincronizar cada dispositivo cada 24 horas, puedes sincronizar cada dispositivo en un período elegido de forma aleatoria entre 23 y 25 horas. Esto ayuda a distribuir la cantidad de solicitudes.

Del mismo modo, si ejecutas un trabajo diario que realiza muchas llamadas a la API consecutivamente, considera iniciar el trabajo de forma aleatoria todos los días para evitar realizar una gran cantidad de solicitudes a todos los clientes empresariales al mismo tiempo.

Usa la retirada exponencial para reintentar las solicitudes

Si ejecutas trabajos que consisten en muchas llamadas a la API, usa una estrategia de retirada exponencial para alcanzar la cuota. La retirada exponencial es un algoritmo que reintenta solicitudes de manera exponencial. A continuación, se muestra un flujo de ejemplo para implementar una retirada exponencial simple:

1. Realiza una solicitud a la API de EMM de Google Play.
2. Recibe una respuesta HTTP 429.
3. Espera 2 segundos + random_time y, luego, vuelve a intentar la solicitud.
4. Recibe una respuesta HTTP 429.
5. Espera 4 segundos + random_time y, luego, vuelve a intentar la solicitud.
6. Recibe una respuesta HTTP 429.
7. Espera 8 segundos + random_time y, luego, vuelve a intentar la solicitud.

Por lo general, random_time es un número aleatorio que va de -0.5 * tiempo de espera a +0.5 * tiempo de espera. Vuelve a definir un random_time nuevo cada vez que lo vuelvas a intentar. Las llamadas a la API que se requieren para completar acciones orientadas al usuario se pueden reintentar con una programación más frecuente (0.5 s, 1 s y 2 s, por ejemplo).

Límite de procesos por lotes

Cada vez que un proceso por lotes alcanza la cuota, la latencia de las acciones del usuario que llaman a la API aumenta. En situaciones como estas, es posible que las estrategias como la retirada exponencial no sean lo suficientemente efectivas para mantener una latencia baja de las acciones del usuario.

A fin de evitar alcanzar los límites de uso de la API repetidas veces y aumentar la latencia para las acciones orientadas al usuario, considera usar un limitador de frecuencia para los procesos por lotes (consulta RateLimiter de Google). Con un limitador de frecuencia, puedes ajustar la frecuencia de tus solicitudes a la API para que siempre estés por debajo de los límites de uso.

Por ejemplo, inicia un proceso por lotes con un límite de frecuencia predeterminado de 50 QPS. Siempre que la API no muestre un error, aumenta lentamente el límite de frecuencia (1% cada minuto). Cada vez que alcances la cuota, reduce tu porcentaje de solicitudes en un 20%. Este enfoque adaptable da como resultado un porcentaje de solicitudes más óptimo y reduce la latencia para las acciones orientadas al usuario.