La API de EMM de Google Play tiene un límite predeterminado de 60,000 consultas por minuto para cada EMM.
Si superas 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 tus usuarios, considera implementar algunas de las prácticas recomendadas que se describen en la siguiente sección.
Recomendaciones para mantenerse por debajo de los límites de uso de las APIs
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.
Aleatoriza las horas y los intervalos de inicio
Es probable 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 a intervalos programados con regularidad, puedes distribuir la carga de solicitudes mediante la aleatorización de estos intervalos. Por ejemplo, en lugar de sincronizar los dispositivos cada 24 horas, puedes sincronizar cada uno en un período seleccionado al azar de entre 23 y 25 horas. Esto ayuda a distribuir la cantidad de solicitudes.
Del mismo modo, si ejecutas una tarea diaria que realiza muchas llamadas a la API en rápida sucesión, considera iniciarla a una hora aleatoria todos los días para evitar realizar un gran volumen de solicitudes para todos tus clientes empresariales al mismo tiempo.
Usa la retirada exponencial para reintentar solicitudes
Si ejecutas tareas que consisten en muchas llamadas a la API, usa una estrategia de tiempo de espera exponencial en respuesta a alcanzar la cuota. La retirada exponencial es un algoritmo que reinyecta solicitudes de forma exponencial. A continuación, se muestra un flujo de ejemplo para implementar una retirada exponencial simple:
- Realiza una solicitud a la API de EMM de Google Play.
- Recibe una respuesta
HTTP 429. - Espera 2 segundos +
random_timey vuelve a intentar la solicitud. - Recibirás una respuesta
HTTP 429. - Espera 4 segundos +
random_timey, luego, vuelve a intentar la solicitud. - Recibe una respuesta
HTTP 429. - Espera 8 segundos +
random_timey vuelve a intentar la solicitud.
Por lo general, random_time es un número aleatorio que varía de -0.5 × tiempo de espera a +0.5 × tiempo de espera. Vuelve a definir un random_time nuevo cada vez que reintentes la
solicitud. Las llamadas a la API que se requieren para completar acciones para el usuario se pueden volver a intentar en un programa más frecuente (por ejemplo, 0.5 s, 1 s y 2 s).
Procesos por lotes con límite de frecuencia
Cada vez que un proceso por lotes alcanza la cuota, aumenta la latencia de las acciones del usuario que llaman a la API. En situaciones como estas, es posible que estrategias como la reducción exponencial no sean lo suficientemente eficaces para mantener una latencia baja para las acciones del usuario.
Para evitar alcanzar los límites de uso de la API de forma reiterada y aumentar la latencia de las acciones orientadas al usuario, considera usar un limitador de frecuencia para tus procesos por lotes (consulta RateLimiter de Google). Con un limitador de frecuencia, puedes ajustar la frecuencia de tus solicitudes a la API para que te mantengas siempre 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 el límite de frecuencia lentamente (1% cada minuto). Cada vez que alcances la cuota, reduce tu porcentaje de solicitudes en un 20%. Este enfoque adaptativo genera una tasa de solicitudes más óptima y, al mismo tiempo, reduce la latencia de las acciones para el usuario.