Siege умеет выполнять многопоточное нагрузочное тестирование web-серверов по протоколу HTTP (S)/1.0/1.1 методами GET и POST. Утилита симулирует параллельные запросы к веб-серверу на протяжении заданного времени и в конце теста вычисляет следующие показатели:
- количество совершённых транзакций в процессе тестирования;
- среднее количество транзакций в секунду;
- длительность самой долгой и самой быстрой транзакций;
- количество и процентное соотношение успешных/неудачных транзакций;
- среднее время, потребовавшееся серверу для ответа;
- объём переданных данных и скорость обмена данными с сервером;
- среднее количество транзакций, которые сервер смог обрабатывать одновременно.
Запросы к серверу утилита может выполнять как к одному и тому же URL, так к разным на основе списка. Паузы между запросами к серверу могут быть как произвольными в пределах заданного интервала, так и вовсе отсутствовать, позволяя таким образом выполнять тест производительности сервера.
Siege присутствует в репозиториях всех популярных дистрибутивов, так что вы должны без труда установить её в своей системе. Если же ваш дистрибутив не располагает утилитой в среди включённых в комплект пакетов, вы можете самостоятельно собрать siege из исходных кодов, полученных со страницы проекта на freshmeat.net.
Условия тестирования, приводимого в этой заметке, те же самые, что и впредыдущей. Следуя схеме тестирования, определённой в предыдущей статье, для начала выполним 1000 последовательных запросов статического HTML-файла:
|
1
|
$ siege –b –c 1 –r 1000 http://aserver.ashep:80/test.html
|
Здесь:
- опция ‘-b’ переключает утилиту в режим тестирования производительности, т. е. siege не будет делать паузу случайной длительности между запросами;
- опция ‘-c’ определяет количество параллельных запросов, отправляемых за один раз. В нашем случае — один;
- при помощи опции ‘-r’ определяется количество повторов запроса.
После выполнения тестирования утилита выведет результаты:
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Transactions: 1000 hits
Availability: 100.00 %
Elapsed time: 10.97 secs
Data transferred: 8.95 MB
Response time: 0.01 secs
Transaction rate: 91.16 trans/sec
Throughput: 0.82 MB/sec
Concurrency: 1.00
Successful transactions: 1000
Failed transactions: 0
Longest transaction: 0.03
Shortest transaction: 0.00
|
Из результатов теста видно, что:
- общее количество транзакций составило 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
|
$ siege –b –c 200 –r 5 http://aserver.ashep:80/test.html
|
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Transactions: 1000 hits
Availability: 100.00 %
Elapsed time: 12.69 secs
Data transferred: 8.95 MB
Response time: 1.70 secs
Transaction rate: 78.80 trans/sec
Throughput: 0.71 MB/sec
Concurrency: 134.16
Successful transactions: 1000
Failed transactions: 0
Longest transaction: 10.26
Shortest transaction: 0.01
|
В результатах этого теста видим значительно возросшее время, требуемое серверу для ответа — 1,7 секунды против 0,01 в предыдущем тесте. При этом на 12 снизилось количество транзакций обрабатываемых за одну секунду. Из генерируемых двухсот одновременных запросов сервер в среднем смог обрабатывать лишь 134,16. Но при всём этом доступность сервера составила 100%, т. е. сервер не был загружен настолько, что был не в состоянии принимать входящие сетевые соединения.
Попробуем выполнить тот же тест, только исключив опцию ‘-b’, что приведёт к снижению нагрузки на сервер за счёт произвольных пауз между транзакциями, что больше приближено к реальному поведению клиентов вашего сервера:
|
1
|
$ siege –c 200 –r 5 http://aserver.ashep:80/test.html
|
|
1
2
3
4
5
6
7
8
9
10
11
12
|
Transactions: 1000 hits
Availability: 100.00 %
Elapsed time: 12.29 secs
Data transferred: 8.95 MB
Response time: 1.52 secs
Transaction rate: 81.37 trans/sec
Throughput: 0.73 MB/sec
Concurrency: 124.05
Successful transactions: 1000
Failed transactions: 0
Longest transaction: 9.32
Shortest transaction: 0.01
|
Как видно, некоторые показатели несколько улучшились, за счёт ухудшения показателя Concurrency, что логично. При необходимости вы можете увеличить диапазон случайно временной задержки между отправкой запросов при помощи опции ‘-d’. Например, чтобы siege выдерживал случайную паузу между запросами в пределах между 0 и 5 секундами:
|
1
|
$ siege –d 5 –c 200 –r 5 http://aserver.ashep:80/test.html
|
Если вам необходимо, чтобы siege «побродил» по вашему серверу вместо того, чтобы тупо долбиться на один и тот-же URL, создайте текстовый файл со списком URL, которые необходимо посетить в процессе тестирования и укажите путь к нему при помощи опции ‘-f’:
|
1
|
$ siege –d 5 –c 200 –r 5 –f ~/urls.txt
|
Чтобы заставить утилиту брать URL из файла не последовательно, а случайно, добавьте опцию ‘-i’:
|
1
|
$ siege –d 5 –c 200 –r 5 –i –f ~/urls.txt
|
При необходимости вы можете ограничить время, которое будет отведено siegeдля выполнения теста, при помощи опции ‘-t’. Обратите внимание, что эта опция имеет приоритет перед опцией ‘-r’. При указании значения опции ‘-t’ можно использовать суффиксы ‘s’, ‘m’ и ‘h’ для определения времени в секундах, минутах и часах соответственно. Например:
|
1
|
$ siege –d 5 –c 200 –t 10s http://aserver.ashep:80/test.html
|
