Rate Limits e boas práticas da API AdWords

API SERVER

Rate Limits
e boas práticas da API

+GustavoMenezes, Google, Inc.


Agenda
● Boas práticas
● O que são Rate Limits?
● Como tratar Rate Limits


Boas Práticas
Pequenas mudanças que melhoram performance


Execute Operações em Batch


● Requisições a API são custosas
● Transferência de rede, serialização, autenticação, etc.

● Agrupar operações reduz o custo
● Métodos mutate aceitam arrays de operações
● MutateJobService executa em batch


Agrupe Operações por Entidade
● Multiplas operações nos mesmo AdGroups ou
Campanhas são rápidas
● Operações seguidas em AdGroups/Campanhas causam
CONCURRENT_MODIFICATION errors
● Servidor pode precisar de tempo para propagar
● Tente editar tudo de uma única vez


Apenas Mude o Que Você Precisa
● Vai atualizar um objeto?
● Envie somente os valores diferentes!
● Enviar tudo desperdiça tempo
●

O sistema ainda vai validar tudo, salvar no BD, etc.


Algumas Outras Idéias…
● Comprima as requisições com gzip
● Inclua gzip no User-Agent
● Accept-Encoding: contém gzip

● Use falha parcial
● A API vai computar as operações
que deram certo
● A API vai retornar as que falharam


Definindo Rate Limits


Rate Limits
● Não são fixos!
● Variam com a carga no servidor
● Variam por funcionalidade
● Variam com a hora
● Diferente para cada serviço


Erros de Rate Limit
● RATE_EXCEEDED
○ espere retryAfterSeconds segundos

● CONCURRENT_MODIFICATIONS
○ Backoff exponencial, tente algumas vezes

● UNEXPECTED_INTERNAL_API_ERROR
○ Backoff exponencial, tente algumas vezes
○ Relate o problema no fórum

Como Tratar Rate Limits
Preste atenção nos detalhes...


Exemplo Básico
Java

ApiError[] errorArray = apiException.getErrors();
for (ApiError apiError : errorArray) {
if (apiError instanceof RateExceededError) {
int seconds = ((RateExceededError) apiError)
.getRetryAfterSeconds();
// wait the amount of seconds the server asked
Thread.sleep(seconds * 1000);
}
}

How to handle Rate Limits

Exemplo Básico - Explicação
● Qualquer req. pode gerar um RateExceededError
● Tratar esses errors é muito importante
● Wait and retry é a melhor estratégia
nesse caso
● Mais importante ainda quando
executando mais de um request


Exemplo Básico - Pontos Importante
● Solução síncrona para o problema
● Bloqueia a Thread até ter sucesso, ou falhar
● Sem controle sobre o rate speed
● Difícil de agrupar operações


Uma Solução Mais Avançada
● Message Queues
● A melhor solução para distribuir carga e
fazer throttling
● Boas soluções disponíveis no mercado
●

ActiveMQ, RabbitMQ, … etc.

● Muitas ferramentas / bibliotecas para
gerenciar a camada de comn.


Message Queues (cont’d)
● Mais controle sobre os rate limits
● Melhor distribuição do código em módulos
● Vamos ver três possíveis soluções para o problema...


1. Fila Única
Producer

Producers criam tarefas para
serem executadas na API, e
despacham para a fila

Producer

Consumers
Consumers
Consumers

X

Queue

Throttling

Producer

Logging

Error

Consumers recebem as mensagens/tarefas
da fila com um rate controlado

Primeira Solução - Pros & Cons
● Pros:
● Muito fácil de implementar
● Apenas um ponto de controle na velocidade
● Fácil de tratar os erros

● Cons:
●
●
●
●

Apenas um ponto de controle na velocidade
Difícil de agrupar operações
Tarefas podem demorar muito para serem executadas
Nem todas as filas implementam prioridade de mensagens


2. Fila Única com Seletores
Producers
Producers

Producers criam tarefas específicas,
e despacham para a fila com o
cabeçalho específico

Producers
Producers

Cada consumer específico agrupa
as operações, e usa seu próprio
rate limit para executá-las
X
X
X
X

Producers
Producers

Queue

Throttling

Producers
Producers

Producers
Consumer


Producers
Consumer
Producers
Consumer
Producers
Consumer

Error

Segunda Solução - Pros & Cons
● Pros:
● Agrupa operações por tipo
● Algum controle na velocidade por tipo
● Mais eficiente - melhor acesso em paralelo da API

● Cons:
●
●
●
●

Apenas uma fila - difícil de administrar
Sem um controle principal de acesso a API
Gerenciar todas as partes pode ser difícil
Log de operações também pode ser difícil


3. Múltiplas Filas
Executors fazem a requisição

Producers
Consumer

Producers
Producers

Producers
Consumer

Throttling

Producers
Producers

Producers
Producers
Producers
Producers

Producers
Consumer
Producers
Consumer

Queues


Producers
Executors
Executors
Executors

Consumers agrupam tarefas
Error
X
X
X
X

Producers criam as
tarefas

Throttling

Logging

Terceira Solução - Pros & Cons
● Pros:
●
●
●
●
●
●

Controle total sobre rate limits
Bastante robusta - fácil adicionar módulos novos
Visão completa do que está acontecendo na fila
Fácil de escalar baseado em demanda
Feito corretamente, é fácil de manter!
Super eficiente - Grouping paralelo; Acesso paralelo a API

● Cons:
● Difícil de implementar corretamente - time experiente


Message Queues - Resumo
● Complexidade da plataforma que escolhe a solução
● Combine partes das soluções!
● Assunto complexo, mas existe retorno no futuro
● Invista muito em monitoramento. MUITO!
● Não existe silver bullet...


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

Perguntas?
Obrigado!


Rate Limits e boas práticas da API AdWords

Recommandé

Recommandé

Contenu connexe

Similaire à Rate Limits e boas práticas da API AdWords

Similaire à Rate Limits e boas práticas da API AdWords (20)

Plus de marcwan

Plus de marcwan (19)

Rate Limits e boas práticas da API AdWords