Список инструментов для проведения нагрузочного тестирования

Инструменты для проведения нагрузочного тестирования скриптов PHP, веб -серверов Apache, Nginx, LiteSpeed Web Server.

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

Так же бывает необходимо нагрузить сайт для выявления ошибок, которые появляются только при нагрузке на сервер.

Подробнее о бенчмарк ab утилите для анализа производительности HTTP серверов, например Apache, Nginx.

Утилита ab подходит как для простого, так и продвинутого тестирования. Проверка максимального количества запросов с TLS:

ab -c 50 -n 10000 -f TLS1.2 -H "Accept-Encoding: gzip,deflate" https://somesite.com/

Команда выполнила 10 000 запросов в 50 потоков и показала скорость и обработанное количество запросов:

Total transferred:      59560000 bytes
HTML transferred:       52160000 bytes
Requests per second:    816.77 [#/sec] (mean)
Time per request:       122.434 [ms] (mean)
Time per request:       2.449 [ms] (mean, across all concurrent requests)
Transfer rate:          2375.33 [Kbytes/sec] received

Из этого отчета самыми важными данными будут:

• Requests per second — количество запросов в секунду. К примеру если страница состоит из 20 частей (CSS, картинки и HTML), то в нашем примере сервер способен обработать около 40 одновременных пользователей в секунду.
• Time per request (mean) — среднее время на выполнение группы параллельных запросов (в нашем случае 50);
• Time per request (mean, across all concurrent requests) — среднее время на выполнение одного запроса.

Apache Bench (ab) пригодится для быстрой и грубой оценки производительности веб-сервера, так что если нужно получить более приближенные к реальности данные, придется воспользоваться дополнительными утилитами.

Утилита httperf, как и ab, проста в использовании, обладает достаточно широким функционалом и запускается также из ксомадной строки Linux.

Создание 100 000 сессий (по 5 вызовов через каждые 2 с) со скоростью 1000:

httperf --hog --server somesite.com --wsess=100000,5,2 --rate 1000 --timeout 5

Connection rate: 1055.0 conn/s (0.9 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 0.3 avg 865.9 max 7912.5 median 459.5 stddev 993.1
Connection time [ms]: connect 31.1
Connection length [replies/conn]: 1.000
Request rate: 1966.6 req/s (0.5 ms/req)
Request size [B]: 91.0
Reply rate [replies/s]: min 59.4 avg 1060.3 max 1639.7 stddev 475.2 (22 samples)

В отчете утилиты стоит сфокусироваться на:

• Connection rate — реальная скорость создания новых соединений. Она показывает способность сервера обрабатывать соединения, то есть в нашем случае до 1055 соед./с, но не более 1022 одновременных соединений.
• Connection time [ms] — время “жизни” успешных соединений между инициализацией и закрытием. Опять же показывает производительность сервера при обработке большого количества соединений.
• Request rate — скорость обработки запросов. То есть, количество запросов, которые сервер способен выполнять за секунду, показывает отзывчивость веб-приложения.

Tsung мощная, продвинутая, мультизадачная и мультипоточная утилита. Tsung написан на Erlang Инструмент может использоваться для нагрузки серверов HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP и Jabber/XMPP. Поддерживается SSL, мониторинг ресурсов системы и агенты SNMP, Munin или Erlang на удаленных серверах, симуляция поведения юзеров и расширенные отчеты.

В Ubuntu 20.04.3 LTS утилита Tsung присутствует в репозитории, ищем командой apt

# apt search ^tsung
Sorting... Done
Full Text Search... Done
tsung/focal 1.7.0-3.1 amd64
  distributed multi-protocol load testing tool

Установка tsung

apt install tsung

Программе tsung нужно передать файл с описанием сценария теста. Вот пример простого тестового сценария:

tsung.xml

<?xml version="1.0"?>
<!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd">
<tsung loglevel="debug" version="1.0">
  <clients>
    <client host="localhost" use_controller_vm="true" maxusers="64000" />
  </clients>
 
  <servers>
    <server host="localhost" port="8087" type="tcp" /> 
  </servers>
 
  <load>
    <arrivalphase phase="1" duration="60" unit="second">
        <users maxnumber="64000" arrivalrate="2500" unit="second" />
    </arrivalphase>
  </load>
 
  <options>
    <option name="ports_range" min="1025" max="65535"/>
  </options>
 
  <sessions>
    <session name="websocket" probability="100" type="ts_websocket">
        <request>
             <websocket type="connect" path="/comet-server/ws/sesion=&amp;myid=&amp;devid=0&amp;v=3.24&amp;uuid=48wTOvoa-uEtC0thHzBkIKir14sXgkOy&amp;api=js"></websocket>
        </request>
 
 
        <for var="i" from="1" to="20000" incr="1">
          <thinktime value="150"/>
        </for>
 
        <request>
            <websocket type="close"></websocket>
        </request>
    </session>
  </sessions>
</tsung>

В нём указано что к localhost к порту 8087 надо подключатся по вебсокетам. И создавать по 2500 тысячи подключений каждую секунду до тех пор, пока их в сумме не наберётся 64000.

То есть этот сценарий просто создаёт тестовую нагрузку в 64000 пользователей онлайн. Тест синтетический и реальные 64000 будут нагружать сервер несколько по другому, а не просто висеть онлайн, но это уже от приложения и предполагаемого сценария использования комет сервера можно составить свой сценарий тестирования, который бы отражал ваш тип нагрузки на комет сервер.

Нагрузка в 64000 это максимум который позволит создать операционная система. Если хотите больше, то надо тестировать один сервер с нескольких машин с tsung одновременно. TCP-соединение уникально определяется четверкой [source ip, source port, dest ip, dest port], таким образом с одной машины на 1 порт сервера можно создать не более 64 тыс одновременных соединений

Отчет будет состоять из графиков и важной дополнительной информации. В нем стоит обратить внимание на:

• Session — общее количество пользователей и количество одновременных сессий в секунду, которые веб-сервер обработал.
• Request — время отклика веб-сервера, его способность и скорость обработки одновременных запросов. К примеру 200 запросов/с значит, что в среднем 10 пользователей сможет одновременно получить зайти на веб-страницу, состоящую в общем из 20 компонентов (CSS, картинки и HTML). А это более 400 000 посетителей за 12 часов.
• Connect — время, требуемое на подключение, то есть отзывчивость веб-сервера.

• Бенчмарк Siege — утилита для нагрузочного тестирования веб-серверов - утилита для регрессивного тестирования и анализа производительности HTTP
• Бенчмарк Tsung It can be used to stress HTTP, WebDAV, SOAP, PostgreSQL, MySQL, LDAP and Jabber/XMPP servers.
• Apache Apache JMeter — инструмент для проведения нагрузочного тестирования
• Locust тестирование нагрузки - инструмент тестирования пользовательской нагрузки. Позволяет писать сценарии на Python.

Apache Bench, Httperf и Tsung отлично подходят для тестирования нагрузки на большие и маленькие сайты.

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