rate limits and performance (russian)


Эффектиные API запросыи ограничения скорости

Danial Klimkin, Google, Inc.

API SERVER


● Эффективное использование API

● Ограничения скорости по

запросам (rate limiting)

● Примеры реализации очередей

запросов для API

План


Эффективное использование APIПростые советы как ускорить ваше приложение


Объединение операций AdWords API Workshops – All rights reserved

● Все запросы к API имеют издержки

● Передача по сети, сериализация, авторизация, etc.

● Группировка операция уменьшает издержки

● Метод mutate принимает массив операций

● MutateJobService для асинхронной обработки


● Несколько операций над одной кампанией

выполняются быстре, чем над разными

● Обращение к одной кампании может вызвать ошибки типа CONCURRENT_MODIFICATION● Работайте с одной кампанией только из одного потока● Фоновые сервисы так же работают с объектами

Объединение по целям


● Изменяете объект?

● Отпарвляйте только изменения!

● Отправка объекта целиком замедляет процесс

● Происходит проверка значений, сохранение в БД...

Отправляйте только изменения


● Используйте сжатие gzip для запросов и ответов.● Включите в User-Agent “gzip”● Accept-Encoding: gzip

● Используйте “partial failure”● Выполяет все операции без ошибок● Возвращает ошибки для остальных

Кроме того…


Определение “ограничения скорости”

AdWords API Workshops – All rights reserved Defining Rate Limits

● Не фиксированы

● Зависят от нагрузки на сервер

● Различны для разных сервисов

● Меняются во времени

● Разнятся для разных запросов

Ограничения скорости запросов

AdWords API Workshops – All rights reserved Defining Rate Limits

● RATE_EXCEEDED○ пауза на retryAfterSeconds секунд

● CONCURRENT_MODIFICATIONS○ увеличивающаяся пауза, повтор

● UNEXPECTED_INTERNAL_API_ERROR○ 1-2 попытки повторить○ свяжитесь с нами, сообщите об ошибке

Ошибки “ограничения скорости”


Что делать при ограничении?Careful coding...


Простой пример

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


● Ошибка RateExceededError может возникнуть при выполнении любого запроса

● Важно обрабатывать эту ошибку● Подождать и повторить -- простейшая

стратегия в этом случае● Особенно важно при выполнении

нескольких связанных запросов

Простой пример -- описание


● Решение -- синхронное

● Вызывающий поток заблокирован

● Нет контроля за скоростью выполнения

● Сложно группировать операции

Важные замечания по примеру


● Очереди сообщений (Message queues)

● Решения для распределения и управление скоростью (throttling) запросов

● Много готовых решений на рынке● ActiveMQ, RabbitMQ, … etc.

● Существуют решения для большинства платформ / языков

Решение на основе очередей


Consumers


1. Одна очередь

Queue

Producer

Producer

Producer

ConsumersThrottling

Производитель создает задачи для выполнения и добавляет из в очередь

Потребитель достает задания из очереди с заданной скоростью

X Error

Consumers

Logging


● За:● Простота реализации● Одна точка управления скоростью запросов● Легко обрабатывать ошибки

● Против:● Только одна точка управления скоростью запросов● Сложно группировать операции● Некоторые задачи будут долго выполняться● Нужна приоритезация и не везде она эффективна

Первое решение -- за и против


Producers

Producers

Producers

Producers


2. Одна очередь с селекторами

Queue

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

Производители создают задачи разных типов и добавляют в очередь

Каждая группа потребителей обрабатывает задачи ее типа, со своей скоростью

XXXX Error


● За:● Группировка заданий по типу● Частичный контроль за скоростью выполнения по

сервисам● Хорошая эффективность -- параллельность запросов

● Против:● Только одна очередь -- управление ограничено● Нет общего контроля скорости выполнения● Больше движущихся частей -- сложнее● Протоколирование усложняется

Второе решение -- за и против

AdWords API Workshops – All rights reserved How to handle Rate Limits

3. Несколько очередей

Producers

Producers

Producers

Producers

Queues

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Producers

Consumer

Consumer

Consumer

Consumer

Throttling

XXXX

Error

ProducersExecutorsExecutorsExecutors

Throttling

Logging

Производители создают задачи

Потребители получают задачи

Исполнители выполняют запрос


● За:● Полный контроль за скоростью выполнения● Модульность и расширяемость● Возможность управления разными очередями● Масштабируемость● Максимальные параллелизм и эффективность

● Против:● Сложность реализации

Третье решение -- за и против


● Решение зависит от масштаба задачи

● Внедрение -- инвестиция

● Следите за логами, очередями, ошибками

● Нет одного идеального решения

Очереди сообщений: итого


Полезные ресурсыAPI 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://activemq.apache.org/

http://www.rabbitmq.com/


Вопросы?Спасибо!

rate limits and performance (russian)

Technology