Эффективное использование API с ограниченной скоростью (Echo Nest) с распределенными клиентами

Вышеприведенное работало, но было очень шумно, а код был в беспорядке. Сейчас я использую более простой подход:

• Позвонить
• Из ответа обратите внимание на лимит и подсчитайте

• Рассчитать

  barrier = now() + 60 / max(1, (limit - count))**greedy
  

• При следующем звонке дождитесь barrier

Идея довольно проста: вы должны подождать некоторое время, пропорциональное тому, как мало запросов осталось в эту минуту. Например, если count равен 39, а limit равен 40, вы ждете целую минуту. Но если count равен нулю, вы можете сделать запрос в ближайшее время. Параметр greedy является компромиссом: когда он больше 1, «первые» вызовы выполняются быстрее, но вы, скорее всего, достигнете предела и в конечном итоге будете ждать 60 секунд.

Производительность этого метода аналогична подходу, описанному выше, и он намного более надежен. Это особенно хорошо, когда клиенты «нестабильны», так как описанный выше подход приводит к путанице при попытке оценить линейные скорости, в то время как это позволит клиенту «украсть» несколько быстрых запросов, когда спрос низкий.

Код здесь.

После некоторых экспериментов оказалось, что самое главное — получить как можно более точную оценку верхнего предела текущих скоростей соединения.

Каждый клиент может отслеживать собственную (локальную) скорость подключения, используя очередь меток времени. Временная метка добавляется в очередь при каждом подключении, а временные метки старше минуты отбрасываются. Затем по первой и последней меткам времени и количеству записей (минус один) определяется «долгосрочная» (более минуты) средняя скорость. «Кратковременную» (мгновенную) скорость можно найти по времени последних двух запросов. Верхний предел – это максимальное из этих двух значений.

Каждый клиент также может оценить скорость внешнего подключения (от других клиентов). «Долгосрочную» скорость можно определить по количеству «использованных» соединений за последнюю минуту, как сообщает сервер, с поправкой на количество локальных соединений (из упомянутой выше очереди). «Краткосрочную» скорость можно оценить по «использованному» номеру с момента предыдущего запроса (минус один для локального соединения), масштабированному по разнице во времени. Опять же, используется верхний предел (максимум из этих двух значений).

Каждый клиент вычисляет эти две скорости (локальную и внешнюю), а затем складывает их для оценки верхнего предела общей скорости соединений с сервером. Это значение сравнивается с целевым диапазоном скорости, который в настоящее время установлен между 80% и 90% от максимума (от 0.8 до 0.9 * 120 в минуту).

Исходя из разницы между расчетной и целевой скоростью, каждый клиент изменяет свою собственную скорость соединения. Это делается путем взятия предыдущей дельты (время между последним подключением и предыдущим) и ее масштабирования на 1.1 (если скорость превышает целевую) или 0.9 (если скорость ниже целевого). Затем клиент отказывается устанавливать новое соединение до тех пор, пока эта масштабируемая дельта не пройдет (переходя в спящий режим, если запрашивается новое соединение).

Наконец, ничто из вышеперечисленного не заставляет всех клиентов в равной степени делить полосу пропускания. Поэтому я добавляю дополнительные 10% к оценке местной ставки. Это приводит к предпочтительному завышению ставки для клиентов с высокими ставками, что повышает вероятность того, что они снизят свою ставку. Таким образом, «жадные» клиенты оказывают несколько более сильное давление на сокращение потребления, которое в долгосрочной перспективе оказывается достаточным для поддержания сбалансированного распределения ресурсов.

Важными выводами являются:

• Принимая максимальные «долгосрочные» и «краткосрочные» оценки, система становится консервативной (и более стабильной) при запуске дополнительных клиентов.

• Ни один клиент не знает общего числа клиентов (если только оно не равно нулю или одному), но все клиенты выполняют один и тот же код, поэтому могут «доверять» друг другу.

• Учитывая вышесказанное, вы не можете сделать «точные» расчеты того, какой курс использовать, но вы можете сделать «постоянную» коррекцию (в данном случае +/- 10% фактор) в зависимости от глобального курса.

• Подстройка частоты подключения клиента производится по дельте между двумя последними подключениями (подстройка по среднему значению за всю минуту слишком медленная и приводит к колебаниям).

• Сбалансированное потребление может быть достигнуто за счет незначительного наказания жадных клиентов.

В (ограниченных) экспериментах это работает довольно хорошо (даже в худшем случае, когда несколько клиентов запускаются одновременно). Основные недостатки: (1) он не допускает начального «взрыва» (что улучшит пропускную способность, если у сервера мало клиентов, а у клиента всего несколько запросов); (2) система все еще колеблется более ~ минуты (см. ниже); (3) обработка большего числа клиентов (в худшем случае, например, если все они запускаются одновременно) требует большего усиления (например, 20% коррекции вместо 10%), что делает систему менее стабильной.

«Использованное» количество, сообщаемое (тестовым) сервером, в зависимости от времени (эпоха Unix). Это для четырех клиентов (выделено цветом), каждый из которых пытается потреблять как можно больше данных.

Колебания исходят от обычного источника - запаздывания сигнала коррекции. Они демпфируются (1) использованием верхнего предела ставок (прогнозирование долгосрочной скорости на основе мгновенного значения) и (2) использованием целевого диапазона. Вот почему ответ, сообщенный кем-то, кто разбирается в теории управления, будет оценен...

Мне не ясно, важно ли отдельно оценивать местные и внешние ставки (они могут помочь, если краткосрочная ставка для одного высока, а долгосрочная ставка для другого высока), но я сомневаюсь, что ее удаление улучшит ситуацию.

В заключение: все примерно так, как я и ожидал, для такого подхода. Это как бы работает, но поскольку это простой подход, основанный на обратной связи, он стабилен только в пределах ограниченного диапазона параметров. Я не знаю, какие альтернативы могут быть возможны.

Поскольку вы используете Echonest API, почему бы вам не воспользоваться преимуществами заголовков ограничения скорости, которые возвращаются при каждом вызове API?

В целом вы получаете 120 запросов в минуту. Есть три заголовка, которые могут помочь вам самостоятельно регулировать потребление API:

X-Ratelimit-Used
X-Ratelimit-Remaining
X-Ratelimit-Limit

**(Обратите внимание на строчную букву «ell» в «Ratelimit» — документация заставляет вас думать, что она должна быть написана с большой буквы, но на практике это строчная буква.)

Эти подсчеты учитывают вызовы, сделанные другими процессами с использованием вашего ключа API.

Довольно аккуратно, да? Ну, боюсь, есть загвоздка...

Эти 120 запросов в минуту действительно являются верхней границей. Вы не можете рассчитывать на это. В документации указано, что значение может колебаться в зависимости от загрузки системы. Я видел, что в некоторых вызовах, которые я сделал, он опускался до 40, а в некоторых случаях видел, что он опускался ниже нуля (я действительно надеюсь, что это была ошибка в API echonest!)

Один из подходов, который вы можете использовать, — это замедлить работу, как только использование (используемое деление на предел) достигнет определенного порога. Имейте в виду, однако, что при следующем звонке ваш лимит загрузки может быть скорректирован настолько значительно, что «используется» больше, чем «лимит».

Это хорошо работает до определенного момента. Поскольку Echonest не регулирует лимит предсказуемым маннаром, на практике трудно избежать 400-х.

Вот несколько ссылок, которые я нашел полезными:

http://blog.echonest.com/post/15242456852/managing-your-api-rate-limit http://developer.ehonest.com/docs/v4/#rate-limits