Rate limits and performance

AdWords API Workshops – All rights reserved


Rate Limitse boas práticas da API

+GustavoMenezes, Google, Inc.

API SERVER


● Boas práticas

● O que são Rate Limits?

● Como tratar Rate Limits

Agenda


Boas PráticasPequenas mudanças que melhoram performance


Execute Operações em Batch AdWords API Workshops – All rights reserved

● 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


● 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

Agrupe Operações por Entidade


● Vai atualizar um objeto?

● Envie somente os valores diferentes!

● Enviar tudo desperdiça tempo● O sistema ainda vai validar tudo, salvar no BD, etc.

Apenas Mude o Que Você Precisa


● 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

Algumas Outras Idéias…


Definindo 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

Rate Limits


● 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

Erros de Rate Limit


Como Tratar Rate LimitsPreste atenção nos detalhes...


Exemplo Básico

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);

}

}

Java

How to handle Rate Limits


● 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 - Explicação


● 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

Exemplo Básico - Pontos Importante


● 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.

Uma Solução Mais Avançada


● 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...

Message Queues (cont’d)


Consumers

1. Fila Única

Queue

Producer

Producer

Producer

ConsumersThrottling

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

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

X Error

Consumers

Logging


● 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

Primeira Solução - Pros & Cons


Producers

Producers

Producers

Producers

2. Fila Única com Seletores

Queue

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

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

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

XXXX Error


● 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

Segunda Solução - Pros & Cons


3. Múltiplas Filas

Producers

Producers

Producers

Producers

Queues

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

XXXX

Error

ProducersExecutorsExecutorsExecutors

Throttling

Logging

Producers criam as tarefas

Consumers agrupam tarefas

Executors fazem a requisição


● 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

Terceira Solução - Pros & Cons


● 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...

Message Queues - Resumo


LinksAPI Best Practices - https://developers.google.com/adwords/api/docs/guides/bestpractices

ActiveMQ - http://activemq.apache.org/RabbitMQ - http://www.rabbitmq.com/

https://developers.google.com/adwords/api/docs/guides/bestpractices



http://www.google.com/url?q=http%3A%2F%2Factivemq.apache.org%2F&sa=D&sntz=1&usg=AFQjCNEbSLTPhgSgFcCjCyhbo_7sm_wAFw

http://www.google.com/url?q=http%3A%2F%2Fwww.rabbitmq.com%2F&sa=D&sntz=1&usg=AFQjCNHcqL0nBWlBoc0flT6fhKWU84u4bQ


Perguntas?Obrigado!


Technology

Rate limits and performance