La API de Google Ads aplica la limitación de frecuencia por consultas por segundo (QPS) en los IDs de cliente y los proyectos de Google Cloud de forma independiente. Además de las solicitudes por minuto (que miden la frecuencia de las llamadas a la API), la API de Google Ads también aplica límites a las operaciones por minuto (que miden la cantidad total de operaciones de la API en las solicitudes). La API de Google Ads usa un algoritmo de bucket de tokens para medir las solicitudes y determinar un límite de QPS adecuado, por lo que el límite exacto varía según la carga general del servidor en un momento determinado.
El objetivo de imponer límites de frecuencia es evitar que un usuario interrumpa el servicio para otros usuarios (ya sea de forma intencional o no) sobrecargando los servidores de la API de Google Ads con un gran volumen de solicitudes.
Las solicitudes que incumplen los límites de frecuencia se rechazan con el error:
RESOURCE_TEMPORARILY_EXHAUSTED.
Puedes tomar el control de tu app y mitigar los límites de frecuencia reduciendo de forma activa la cantidad de solicitudes y limitando las QPS desde el cliente.
Existen varias formas de reducir las probabilidades de superar el límite de frecuencia. Familiarizarte con los conceptos de Enterprise Integration Patterns (EIP) como la mensajería, la reentrega y la limitación, puede ayudarte a compilar una app cliente más sólida.
Las siguientes prácticas recomendadas se ordenan por complejidad, con estrategias más simples en la parte superior y arquitecturas más sólidas, pero sofisticadas, después:
- Retirada exponencial
- Limitar las tareas simultáneas
- Solicitudes por lotes
- Limitación y limitadores de frecuencia
- Agregar a la fila
Retirada exponencial
Cuando tu aplicación reciba un
RESOURCE_TEMPORARILY_EXHAUSTED error, usa una
política de retirada exponencial con fluctuación aleatoria antes de volver a intentar la
solicitud fallida. La retirada exponencial aumenta progresivamente el tiempo de espera entre los reintentos (por ejemplo, esperar 2 segundos, luego 4 segundos, luego 8 segundos, más un pequeño retraso aleatorio), lo que permite que la carga del servidor y los buckets de cuota se recuperen y, al mismo tiempo, evita los picos de reintento sincronizados en las instancias del cliente.
Limitar las tareas simultáneas
Una de las causas principales de superar los límites de frecuencia es que la app cliente genera una cantidad excesiva de tareas paralelas. Si bien no limitamos la cantidad de solicitudes paralelas que puede tener una app cliente, esto puede superar el límite de solicitudes por segundo a nivel del proyecto de Google Cloud.
Se recomienda establecer un límite superior razonable para la cantidad total de tareas simultáneas que realizarán solicitudes (en todos los procesos y máquinas) y ajustarlo hacia arriba para optimizar tu capacidad de procesamiento sin superar el límite de frecuencia.
Además, puedes considerar limitar las QPS desde el cliente (consulta Limitación y limitadores de frecuencia).
Agrupar las solicitudes por lotes
Considera agrupar varias operaciones en una sola solicitud. Esto es más aplicable a las llamadas Mutate para varios servicios. Por ejemplo, si actualizas el estado de varias instancias de AdGroupAd, puedes llamar a MutateAdGroupAds una vez y pasar varias operations en lugar de llamar a MutateAdGroupAds una vez por cada AdGroupAd. Consulta nuestra
guía de operaciones por lotes para obtener algunos ejemplos adicionales.
Si bien agrupar las solicitudes en lotes reduce la cantidad total de llamadas a la API y mitiga los límites de frecuencia en solicitudes por minuto, puede activar el límite de frecuencia de operaciones por minuto si realizas una gran cantidad de operaciones en una sola cuenta.
Limitación y limitadores de frecuencia
Además de limitar la cantidad total de subprocesos en tu aplicación, también puedes implementar limitadores de frecuencia en el cliente. Esto garantiza que todos los subprocesos de tus procesos, clústeres o ambos se rijan por un límite de QPS específico desde el cliente.
Consulta el Guava RateLimiter o implementa tu propio algoritmo de bucket de tokens para un entorno agrupado. Por ejemplo, puedes administrar tokens en un almacén de datos distribuido en memoria de baja latencia, como Redis o Memcached, en el que cada cliente adquiere y consume un token antes de procesar una solicitud. Si se agotan los tokens, el cliente espera hasta que se reponga el siguiente lote de tokens.
Agregar a la fila
Una cola de mensajes es la solución para la distribución de la carga de operaciones, al mismo tiempo que controla las tasas de solicitudes y consumidores. Hay varias opciones de colas de mensajes disponibles (algunas de código abierto y otras patentadas), y muchas de ellas pueden funcionar con diferentes lenguajes.
Cuando usas colas de mensajes, puedes tener varios productores que envían mensajes a la cola y varios consumidores que procesan esos mensajes. Se pueden implementar limitaciones en el consumidor limitando la cantidad de consumidores simultáneos o implementando limitadores de frecuencia o limitadores para los productores o los consumidores.
Por ejemplo, si un consumidor de mensajes encuentra un error de límite de frecuencia, puede devolver la solicitud a la cola con un retraso de reintento estandarizado (con retirada exponencial) y actualizar un bucle de retroalimentación de limitador de frecuencia compartido para que todos los consumidores reduzcan automáticamente su tasa de procesamiento mientras se recuperan del error.