Debido a que la API de Google Workspace Events es un servicio compartido, aplicamos cuotas y limitaciones para asegurarnos de que todos los usuarios la usen de manera justa y para proteger el rendimiento general de Google Workspace.
Si superas una cuota, recibirás una respuesta de código de estado HTTP 429: Too many requests. Las verificaciones de límite de frecuencia adicionales en el backend de la API de Eventos de Google Workspace también pueden generar la misma respuesta de error. Si ocurre este error, debes usar un algoritmo de retirada exponencial y volver a intentarlo más tarde. Siempre que no superes las cuotas por minuto que se indican en las siguientes tablas, no habrá límite para la cantidad de solicitudes que puedes realizar por día.
Cuotas por proyecto
Las cuotas por proyecto limitan la frecuencia de consultas para un proyecto de Google Cloud y, por lo tanto, se aplican a una sola app que llama a los métodos especificados de la API de Eventos de Google Workspace para cada cuota.
En la siguiente tabla, se detallan los límites de consultas por proyecto. También puedes consultar estos límites en la página Cuotas de Google Cloud Console.
Cuota por proyecto |
Métodos de la API de Google Workspace Events |
Límite |
|---|---|---|
Operaciones de escritura por minuto |
|
600 |
Operaciones de escritura por minuto y por usuario |
|
100 |
Operaciones de lectura por minuto |
|
600 |
Operaciones de lectura por minuto, por usuario |
|
100 |
Resuelve errores de cuotas basadas en el tiempo
Para todos los errores basados en el tiempo (máximo de N solicitudes por X minutos), te recomendamos que tu código detecte la excepción y use una retirada exponencial truncada para asegurarte de que los dispositivos no generen una carga excesiva.
La retirada exponencial es una estrategia estándar de manejo de errores para aplicaciones de red. Un algoritmo de retirada exponencial vuelve a intentar las solicitudes mediante tiempos de espera que aumentan de forma exponencial entre solicitudes, hasta un tiempo de retirada máximo. Si las solicitudes aún no se completan, es importante que las demoras entre ellas aumenten con el tiempo hasta que se realicen correctamente.
Algoritmo de ejemplo
Un algoritmo de retirada exponencial vuelve a intentar las solicitudes de forma exponencial, lo que aumenta el tiempo de espera entre los reintentos hasta un tiempo de retirada máximo. Por ejemplo:
- Realizar una solicitud a la API de Google Workspace Events
- Si la solicitud falla, espera 1 +
random_number_millisecondsy vuelve a intentar la solicitud. - Si la solicitud falla, espera 2 +
random_number_millisecondsy vuelve a intentar la solicitud. - Si la solicitud falla, espera 4 +
random_number_millisecondsy vuelve a intentar la solicitud. - Y así sucesivamente, hasta un tiempo de
maximum_backoff. - Continúa con la espera y los reintentos hasta una cantidad máxima de reintentos, pero no aumentes el período de espera entre los reintentos.
Donde:
- El tiempo de espera es de
min(((2^n)+random_number_milliseconds), maximum_backoff), connincrementado en 1 por cada iteración (solicitud). random_number_millisecondses una cantidad aleatoria de milisegundos menor o igual que 1,000. Esto ayuda a evitar los casos en los que muchos clientes se sincronizan por alguna situación y todos vuelven a intentarlo a la vez, lo que envía solicitudes en conjuntos sincronizados. El valor derandom_number_millisecondsse vuelve a calcular después de cada solicitud de reintento.maximum_backoffsuele ser de 32 o 64 segundos. El valor apropiado depende del caso práctico.
El cliente puede volver a intentarlo después de que se cumpla el tiempo maximum_backoff.
Después de este punto, los reintentos no necesitan seguir aumentando el tiempo de retirada. Por ejemplo, si un cliente usa un tiempo maximum_backoff de 64 segundos, después de alcanzar este valor, puede volver a intentarlo cada 64 segundos. En algún momento, se debe evitar que los clientes vuelvan a intentarlo de forma indefinida.
El tiempo de espera entre los reintentos y la cantidad de reintentos dependen de tu caso de uso y las condiciones de la red.
Solicita un aumento de la cuota por proyecto
Según el uso de recursos de tu proyecto, es posible que desees solicitar un aumento de cuota. Se considera que las llamadas a la API realizadas por una cuenta de servicio usan una sola cuenta. Solicitar una cuota mayor no garantiza la aprobación. Los grandes aumentos de cuota pueden tardar más tiempo en aprobarse.
No todos los proyectos tienen las mismas cuotas. Como usas cada vez más Google Cloud con el tiempo, es posible que tus cuotas deban aumentar. Si prevés un aumento considerable en el uso, puedes solicitar ajustes en la cuota de forma proactiva en la página Cuotas de la consola de Google Cloud.
Para obtener más información, consulta los siguientes recursos: