Rate limits and performance (Spanish)

Rate Limits
(Límites de frequencia)

y buenas praxis de la API

+GustavoMenezes, Google, Inc.


API SERVER

Agenda
● Buenas praxis de la API
● ¿Qué son Rate Limits?
● ¿Cómo manejarlos?


Buenas Praxis
Pequeños detalles para mejorar el rendimiento


Agrupar Operaciones


● Las Peticiones a la API tienen costos
● Transferencia de red, serialización, autenticación, etc.

● Agrupar de las operaciones en una única petición
● Los Métodos mutate aceptan más de una operación
● MutateJobService para agrupar


Agrupar Operaciones por Tipo
● Múltiples operaciones en los mismos AdGroup /
Campaign son más rápidas
● Subsecuentes ediciones en los mismos AdGroup o
Campaign pueden generar errores de tipo
CONCURRENT_MODIFICATION
● Los servidores pueden tomar tiempo para hacer su trabajo
● Intenten hacer todas las operaciones en
AdGroups/Campaigns a la vez

Actualizen Sólo lo Necesario
● ¿Actualizando un objeto?
● Sólo envíen los valores que cambian!
● Enviar los otros valores es un derroche
●

El sistema va a validar, guardar en la BD, etc.


Más Ideas…
● Compriman sus peticiones /
respuestas con gzip
● Aseguren que User-Agent: use “gzip”
● Accept-Encoding: con listado gzip

● Usen la función de fallo parcial
● Fuerza que la API serielice las
operaciones exitosas
● Responde un listado con las operaciones
fallidas

Definiendo Rate Limits


Rate Limits
● No son fijos
● Varían de acuerdo con la carga
● Varían por funcionalidad
● Cambian con el tiempo
● Son diferentes por servicio


Errores de Rate Limits
● RATE_EXCEEDED
○ esperen por retryAfterSeconds segundos

● CONCURRENT_MODIFICATIONS
○ Parada exponencial, intenten pocas veces

● UNEXPECTED_INTERNAL_API_ERROR
○ Parada exponencial, intenten pocas veces
○ Informen del problema al CSR o por fórum

Cómo Manejar Los Rate Limits
Programe con cuidado...


Ejemplo Básico
Java

ApiError[] errorArray = apiException.getErrors();
for (ApiError apiError : errorArray) {
if (apiError instanceof RateExceededError) {
int seconds = ((RateExceededError) apiError)
.getRetryAfterSeconds();
// esperen por la cantidad de segundos retornados
Thread.sleep(seconds * 1000);
}
}

Ejemplo Básico - Explicación
● Cualquier petición puede generar un
RateExceededError

● Manejar los errores es muy importante
● Esperar y volver a intentar es la mejor
estrategia
● Aún más importante para múltiples
peticiones


Puntos Importantes del Ejemplo Básico
● Una solución sincrónica para el problema
● Bloquea el thread hasta que tenga éxito o falle
completamente
● No hay control sobre la frecuencia de las peticiones
● Es muy difícil agrupar operaciones


Una Solución un Poco Más Avanzada
● Message Queues
● La solución perfecta para distribuir carga y
hacer throttling
● Hay soluciones existentes muy buenas
●

ActiveMQ, RabbitMQ, … etc.

● Muchas herramientas / client libraries para
manejar esta franja de comunicación


Message Queues (cont.)
● Mayor control de la velocidad y de los límites
● Mejor separación de los módulos
● A continuación estudiaremos tres ejemplos que
solucionan el problema...


1. Cola Única
Producer

Productores crean tareas que son
ejecutadas en la API, y añadidas a
la cola

Producer

Consumers
Consumers
Consumers

X

Queue

Throttling

Producer

Logging

Error

Consumidores obtienen los mensajes/tareas
de la cola para ejecutarlas

How to handle Rate Limits

Primera Solución - Pros & Contras
● Pros:
● Muy fácil de implementar
● Sólo hay un punto de control de velocidad de peticiones
● Fácil de manejar errores

● Contras:
●
●
●
●

Sólo hay un punto de control de velocidad de peticiones
Difícil de agrupar operaciones
Las Tareas pueden retrasar la cola
No todas MQs manejan mensajes prioritarios


2. Cola Única con Selectores
Producers
Producers

Productores crean tareas específicas,
y las añaden a la cola con un
encabezado específico

Producers
Producers

Cada consumidor específico puede
agrupar las operaciones y
ejecutarlas a su ritmo
X
X
X
X

Producers
Producers

Queue

Throttling

Producers
Producers

Producers
Consumer


Producers
Consumer
Producers
Consumer
Producers
Consumer

Error


Segunda Solución - Pros & Contras
● Pros:
● Agrupación de operaciones por tipo
● Algún control de throttling por tipo
● Mayor eficiencia - mejor acceso paralelo a la API

● Contras:
●
●
●
●

Sólo una cola - difícil de administrar
No hay control principal de velocidad
Manejar todas las partes puede ser difícil
Logging de operaciones puede ser complicado


3. Colas Múltiples Queues
Executors do the request

Producers
Consumer

Producers
Producers

Producers
Consumer

Throttling

Producers
Producers

Producers
Producers
Producers
Producers

Producers
Consumer
Producers
Executors
Executors
Executors

Producers
Consumer
Queues

Consumers just group the tasks
Error

Logging

X
X
X
X

Producers just spawn
a lot of tasks

Throttling



Tercera Solución - Pros & Contras
● Pros:
●
●
●
●
●
●

Total control de velocidad de acceso
Muy robusto - muy fácil de añadir nuevas partes
Visión total de lo que pasa en el sistema
Fácil de crecer basado en demanda
Si esta hecho correctamente, es fácil de mantener!
Muy eficiente - Agrupación paralela; Acceso paralelo a la API

● Contras:
● Difícil de implementar correctamente - se necesita práctica


Message Queues - Resumen
● Complejidad de su sistema determina la mejor solución
● Se pueden combinar partes de las soluciones!
● Es un tema complejo, pero le ayudará en el futuro
● Inviertan mucho en monitorizar. ¡Mucho!
● No hay un comodín...


Enlaces
API Best Practices - https://developers.google.
com/adwords/api/docs/guides/bestpractices
ActiveMQ - http://activemq.apache.org/
RabbitMQ - http://www.rabbitmq.com/

¿Preguntas?
¡Muchas gracias!


Rate limits and performance (Spanish)

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (6)

Similar a Rate limits and performance (Spanish)

Similar a Rate limits and performance (Spanish) (20)

Más de marcwan

Más de marcwan (17)

Último

Último (20)

Rate limits and performance (Spanish)