Тестирование нагрузки на сайт

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

Apache Bench

Наверное, один из самых простых в использовании и популярных тестов для проверки нагрузки на сайт. Утилита подходит как для простого, так и продвинутого тестирования:

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

# Проверка максимального количества запросов с TLS

Команда выполнила 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) — среднее время на выполнение одного запроса.

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

Httperf

Этот тест с открытым исходным кодом был разработан в HP для измерения производительности веб-сервера. Инструмент не обновлялся несколько лет, но все еще является весьма актуальным.

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

httperf --hog --server 192.168.122.10 --wsess=100000,5,2 --rate 1000 --timeout 5

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

А лог будет выглядеть так:

Total: connections 117557 requests 219121 replies 116697 test-duration 111.423 s

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)
Reply time [ms]: response 56.3 transfer 0.0
Reply size [B]: header 267.0 content 18.0 footer 0.0 (total 285.0)
Reply status: 1xx=0 2xx=116697 3xx=0 4xx=0 5xx=0

CPU time [s]: user 9.68 system 101.72 (user 8.7% system 91.3% total 100.0%)
Net I/O: 467.5 KB/s (3.8*10^6 bps)

# Кроме всего прочего, производительность показывает величина скорости запросов (Request rate)

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

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

Но для более глубокой проверки и существенной нагрузки придется использовать еще более продвинутые инструменты.

Tsung

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

Инструмент написан на Erlang, так что для начала необходимо установить нужные репозитории, а затем скачать и установить Tsung:

wget http://tsung.erlang-projects.org/dist/tsung-1.6.0.tar.gz
tar zxfv  tsung-1.6.0.tar.gz
cd tsung-1.6.0
./configure && make && make install

# Распаковка и компиляция утилиты

Все настройки инструмента необходимо прописать в его файле конфигурации:

cp  /usr/share/doc/tsung/examples/http_simple.xml /root/.tsung/tsung.xml

# Копирование шаблона файла конфигурации в директорию Tsung

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

<?xml version="1.0"?><tsung loglevel="notice" version="1.0">

  <clients>
    <client host="localhost" use_controller_vm="true" maxusers="10000"/>
  </clients>

<servers>
	<server host="192.168.122.10" port="80" type="tcp"/>
</servers>

<load>
	<arrivalphase phase="1" duration="1" unit="minute">
		<users maxnumber="10000" interarrival="0.05" unit="second"/>
	</arrivalphase>
</load>

 <sessions>
<session name="stack" probability="100" type="ts_http">
   <for from="1" to="10000" var="i">
    <request><http url="/stack/" version="1.1" method="GET"/></request>
   </for>
  </session>
 </sessions>
</tsung>

# Можно указывать дополнительные опции (к примеру браузеры юзеров), множества нодов для симуляции пользователей

Теперь можно запускать tsung:

tsung -f tsung.xml start
Starting Tsung
"Log directory is: /root/.tsung/log/20160428-1117"

# Для запуска с множества нодов их нужно предварительно указать в настройках

Когда утилита закончила свою работу, можно просмотреть отчет:

mkdir report_output
cd report_output
/usr/lib/tsung/bin/tsung_stats.pl --stats /root/.tsung/log/20160428-1117/tsung.log
chromium graph.html 

# Указывается предпочтительный браузер

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

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

Дополнительные графики позволят оценить нагрузку на веб-сервер за все время тестирования, отследить возникшие ошибки и динамику.

Другие утилиты

Конечно же список инструментов для проверки производительности веб-сервера и тестирования нагрузки на сайт не ограничивается приведенным в этом материале. Таких утилит огромное множество, как платных, так и бесплатных. Существуют сайты для генерации нагрузки, типа LoadImpact, утилиты для запуска из командной строки и полноценные программы с GUI. Одной из самых популярных с пользовательским интерфейсом, кстати, является Apache JMeter — мощная, продвинутая и достаточно сложная.

Самое главное

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

Подпишитесь на Хайлоад с помощью Google аккаунта
или закройте эту хрень