HighLoad.org – блог о высоких нагрузках
HighLoad.org > Принцип высокодоступной системы: очередь запросов

Принцип высокодоступной системы: очередь запросов
2010-03-04 19:26 my_fess  
В моем предыдущем посте о управление параллельностью я говорил о том, что из-за экспоненциального роста времени ответа от увеличения параллельных запросов лучше отклонить лишние запросы, чем позволить им негативно влиять на вашу систему. Такой метод является выходом, но не самым желаемым. Очередь запросов предоставляет более мощное решение.

Пример очереди запросов

Для простоты предположим следующие характеристики системы без управления параллельностью и без очереди запросов:
  • при 500 параллельных соединениях среднее время ответа - 1 секунда
  • при 600 параллельных соединениях среднее время ответа - 2 секунды на выполнение всех запросов
  • при 700 параллельных соединениях время ответа - 4 секунды на выполнение всех запросов
Экспоненциальное снижение производительности начинается при более 500-та параллельных запросов. Учитывая эти числа, предположим, что вы настроили управление параллельностью так, что пропускаете 500 запросов, а следующие 1000 запросов (501-1500) будут ждать. Таким образом: максимальный размер очереди - 1000. Теперь предположим, что произошел неожиданный рост трафика - 1501 запрос. Вот что произойдет:
  1. Первые 500 запросов пройдут и будут обработаны за 1 секунду. Следующие 1000 (501-1500 запросы) поместятся в очередь. 1501-ый запрос будет отклонен.
  2. После того как 1-500 запросы обработаются, дальше будут обрабатываться 501-1000. Таким образом 501-1000 запросы обработаются в сумме за 2 секунды (1 секунда на их выполнение и 1 секунду они находились в очереди).
  3. После того, как обработаются 501-1000 запросы, дальше начнут обрабатываться 1001-1500. Таким образом запросы 1001-1500 обработаются в сумме за 3 секунды (1 секунда на выполнение и 2 секунды они находились в очереди).

Характеристики системы с очередью запросов

  1. Очередь запросов позволяет вашей системе работать с оптимальной пропускной способностью. В приведенном примере: оптимальная пропускная способность была 500 запросов в секунду. Оптимальная пропускная способность как раз чуть ниже, чем количество параллельных запросов, при которых начинается экспоненциальный рост времени ответа. Все время система работала с этой оптимальной пропускной способностью.
  2. Ваши пользователи чувствуют только линейное падение производительности вместо экспоненциального. Как показано на диаграмме, без очереди запросов ваши пользователи и ваша система столкнутся с экспоненциальным падением производительности после 500 запросов. Запросы 0-500 займут 1 секунду, 501-1000 займут 2 секунды, 1001-1500 займут 3 секунды и так далее — с очередью запросов время ответа возрастает линейно.
  3. Производительность вашей системы не падает — вот что главное. Система постоянно работает с оптимальной пропускной способностью. Единственное меняющееся свойство - это размер очереди запросов. Система остается в зеленой зоне — как показано на диаграмме.
Если даже при необычной высокой нагрузке ваша система удовлетворяет 3 вышеперечисленным характеристикам — то у вас все очень хорошо. HAProxy — одно из решений, которое реализует и управление параллельностью и очередь запросов и это одно из решений, которое должно быть рассмотрено для создания высокодоступной системы.

Автор статьи: Ashish Soni Дата: 24 февраля 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD