Нагрузочное тестирование web-сервера при помощи siege






Продолжая тему нагрузочного тестирования web-серверов, сегодня рассмотрим ещё один инструмент с именем siege. За наводку спасибо читателю Dmitry Paskal.


Siege умеет выполнять многопоточное нагрузочное тестирование web-серверов по протоколу HTTP (S)/1.0/1.1 методами GET и POST. Утилита симулирует параллельные запросы к веб-серверу на протяжении заданного времени и в конце теста вычисляет следующие показатели:

  • количество совершённых транзакций в процессе тестирования;
  • среднее количество транзакций в секунду;
  • длительность самой долгой и самой быстрой транзакций;
  • количество и процентное соотношение успешных/неудачных транзакций;
  • среднее время, потребовавшееся серверу для ответа;
  • объём переданных данных и скорость обмена данными с сервером;
  • среднее количество транзакций, которые сервер смог обрабатывать одновременно.

Запросы к серверу утилита может выполнять как к одному и тому же URL, так к разным на основе списка. Паузы между запросами к серверу могут быть как произвольными в пределах заданного интервала, так и вовсе отсутствовать, позволяя таким образом выполнять тест производительности сервера.

Siege присутствует в репозиториях всех популярных дистрибутивов, так что вы должны без труда установить её в своей системе. Если же ваш дистрибутив не располагает утилитой в среди включённых в комплект пакетов, вы можете самостоятельно собрать siege из исходных кодов, полученных со страницы проекта на freshmeat.net.

Условия тестирования, приводимого в этой заметке, те же самые, что и в предыдущей. Следуя схеме тестирования, определённой в предыдущей статье, для начала выполним 1000 последовательных запросов статического HTML-файла:

Здесь:

  • опция '-b' переключает утилиту в режим тестирования производительности, т. е. siege не будет делать паузу случайной длительности между запросами;
  • опция '-c' определяет количество параллельных запросов, отправляемых за один раз. В нашем случае — один;
  • при помощи опции '-r' определяется количество повторов запроса.

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

Из результатов теста видно, что:

  • общее количество транзакций составило 1000;
  • «доступность» (т. е. процент успешных сокет-подключений ) сервера составила 100%;
  • тест занял 10,97 секунд;
  • было передано 8,95 мегабайт данных;
  • среднее время, потребовавшееся серверу для ответа составил 0,01 секунды;
  • в среднем за одну секунду удалось выполнять 91,16 транзакций;
  • средняя скорость обмена данными с сервером составила 0,82 мегабайта в секунду;
  • параллельно сервер обрабатывал один запрос;
  • было успешно (HTTP-код ответа сервера <400) обработано 1000 транзакций;
  • не удалось обработать (HTTP-код ответа сервера >=400) обработано 0 транзакций;
  • длительность самой длинной по времени транзакции составила 0,03 секунды;
  • длительность самой длинной по времени транзакции составила 0,00 секунд.

Попробуем теперь выполнить запрос того же URL 1000 раз, только теперь одновременно будем отправлять по 200 запросов за раз:

В результатах этого теста видим значительно возросшее время, требуемое серверу для ответа — 1,7 секунды против 0,01 в предыдущем тесте. При этом на 12 снизилось количество транзакций обрабатываемых за одну секунду. Из генерируемых двухсот одновременных запросов сервер в среднем смог обрабатывать лишь 134,16. Но при всём этом доступность сервера составила 100%, т. е. сервер не был загружен настолько, что был не в состоянии принимать входящие сетевые соединения.

Попробуем выполнить тот же тест, только исключив опцию '-b', что приведёт к снижению нагрузки на сервер за счёт произвольных пауз между транзакциями, что больше приближено к реальному поведению клиентов вашего сервера:

Как видно, некоторые показатели несколько улучшились, за счёт ухудшения показателя Concurrency, что логично. При необходимости вы можете увеличить диапазон случайно временной задержки между отправкой запросов при помощи опции '-d'. Например, чтобы siege выдерживал случайную паузу между запросами в пределах между 0 и 5 секундами:

Если вам необходимо, чтобы siege «побродил» по вашему серверу вместо того, чтобы тупо долбиться на один и тот-же URL, создайте текстовый файл со списком URL, которые необходимо посетить в процессе тестирования и укажите путь к нему при помощи опции '-f':

Чтобы заставить утилиту брать URL из файла не последовательно, а случайно, добавьте опцию '-i':

При необходимости вы можете ограничить время, которое будет отведено siege для выполнения теста, при помощи опции '-t'. Обратите внимание, что эта опция имеет приоритет перед опцией '-r'. При указании значения опции '-t' можно использовать суффиксы 's', 'm' и 'h' для определения времени в секундах, минутах и часах соответственно. Например:




Нагрузочное тестирование web-сервера при помощи siege: 3 комментария

  1. Замечательно:) Будь я котом, эта статья была бы равнозначна почесыванию за ухом:)

  2. Использую $ siege -d 5 -c 200 -r 5 -f ~/urls.txt

    но почему-то всего 1000 транзакции, как будто-то всего первую строчку берёт, и не берёт остальные (

Комментарии запрещены.