Часто у нас стоит задача протестировать какую нагрузку выдерживает сайт наших клиентов. Для себя, в качестве инструмента тестирования, мы выбрали yandex-tank. Это будет краткая заметка о том как быстро начать работать с этим инструментом.



И так, по порядку. Ставили мы yandex tank на CentOS 7. Сразу скажу на 6-ом он не запустился, а вот на 7 запустился на ура. Чтобы его поставить:

yum install libxml2-devel libxslt1-devel python-devel zlib1g-devel python-pip
pip install --upgrade pip  
yum groupinstall 'Development Tools'
pip install yandextank  

После выполнения этих несложных действий мы получили рабочее ядро танка. Но нам надо еще поставить генератор запросов. В качестве генератора мы выбрали phantom, также можно использовать jmetr и другие. Для установки phantoma достаточно выполнить следующее:

yum install perl openssl-devel binutils-devel make git -y
git clone https://github.com/mamchits/phantom.git
cd phantom
make -R all
mv ./bin/phantom /usr/bin/
mv ./lib/phantom/ /usr/lib/

Уже почти все готово к использованию, осталось только подготовить файл с конфигурацией теста, у нас он выглядит примерно так:

[loadosophia]
token=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
project=centos-admin
test_title=centos-admin.ru

[aggregator]
time_periods  = 1ms 2 3 4 5 6 7 8 9 10 20 30 40 50 60 70 80 90 100 150 200 250 300 350 400 450 500 600 650 700 750 800 850 900 950 1s 1500 2s 2500 3s 3500 4s 4500 5s 5500 6s 6500 7s 7500 8s 8500 9s 9500 10s 11s 12s 13s 14s 15s 16s 17s 18s 19s 20s 21s 22s 23s 24s 25s 26s 28s 29s 30s 100s 300s

[web]
port = 80 ;
interval = 1 ;
manualstop = 1 ;

[phantom]
address = 176.9.95.100
;ssl = 1
port = 80
rps_schedule=step(10,100,10, 10s) ;load schemei

; Headers and URIs for GET requests
header_http = 1.1
headers = [Host: centos-admin.ru]
;    [Authorization: Basic xxxxxxxxxxxxxx]
    [Connection: close]
uris =  /
        /rates

[autostop]
autostop=time(2s,2s)
  http(5xx,100%,2s)
  net(xx,10,30)

Теперь немного о том, что всё это значит:

1. [loadosophia] это раздел который описывает куда складывать отчеты. Для его настройки необходимо зарегестрироваться на loadosophia.org, сгенерировать там token и указать его в конфигурационном файле.
Также удобно указывать test_title, чтобы при тестировании нескольких сайтов можно было разделить отчеты.

2. [aggregator] интервалы, по которым будет вестись округление результатов, разделители списка — пробелы

3. [web] модуль запускает локальный веб-сервер, показывающий графики онлайн-теста.

4. [phantom]

address — адрес сервера на котором распологается сайт. Может быть задан как в виде iP так и URL
ssl — используется ли ssl, 1 — да, 0 — нет
port — порт сайта
rps_schedule самое интересное, он показывает как будет подаваться нагрузка. и тут возможны 3 варианта:

step(start rps,stop rps, step, time)
Copy
start rps — со-скольки rps начинать.
stop rps — до скольки rps выполнять тест.
step — по сколько rps прибавлять.
time — время каждого шага.

Постоянная нагрузка:

const(rps, time)
Copy
По возрастающей:

line(star rps, stop rps, time)
Copy
Пример: step(10,50, 3, 60s) — в этом случае тест начнется с 10 rps, и каждые 60 секунд будет добавлять по 3 rps пока не дойдет до 50 rps.

headers — заголовки, передаваемые с запросом.
Пример: [Host: centos-admin.ru] чтобы можно было определить какой vhost;
[Authorization: Basic dmd1cnlhbm92Ok1pbGVuaXVtMzIx] — если нужна авторизация;
[Connection: close] — чтобы сервер закрывал сразу подключение, а не по таймауту.

uris — список uri по которым будет идти тест

ammofile — вместо uris, задается имя файла, в котором содержится список запросов.

instances — максимальное число тестирующих потоков/

5. [autostop] раздел в котором определяется в каком случае прекратить тестирование.

time — остановить тест, если среднее время ответа превышает заданный порог в течение заданного времени, код выхода 21. Например: time(1s500ms, 30s) time(50,15)
http — остановить тест, если число кодов HTTP, соответствующих маске, больше заданного абсолютного или относительного порога, код выхода 22. Примеры: http(404,10,15) http(5xx, 10%, 1m)
net — аналогично HTTP-кодам, но для сетевых кодов ответа, код выхода 23. допустима маска xx, означающая «все ненулевые»

Ну и немного о том как выглядят отчеты:

Вкладка Summary: общие данные теста.

Вкладка Distributions: Содержит данные по распределению времени ответа на запрос. Проще говоря, сколько запросов было получено за период времени n:
Количество ответов за 0-100,100-200 мс и т.д.
!!!
Какой % ответов было получен за время n:


Вкладка Timelines: Распределение времени ответа в зависимости от ответа.


Важные показатели:
TPS (transaction per sec) тоже самое, что и rps.
VU сколько параллельных процессов было запущенно чтобы обеспечить заданное количество rps.
TPS = (1000 / responce time) * VU.

Наиболее интересный график:
Среднее время отклика для заданного количества rps


Вкладка Target Monitoring:
Здесь выводятся параметры тестируемой сети, если на нее установлен агент. Устанавливается автоматически по ssh.
Остальные вкладки являются вариацией.

Ну и напоследок, для тех кто дочитал до конца) Расскажу о том, как мы это используем. Обычно, в начале мы включаем на сервере всевозможное логирование, и запускаем быстрый тест с неограниченным rps(~ 10000). Смотрим сколько выдерживает сервер и запоминаем это число. Дальше идет процесс оптимизации сервера, просмотр логов, поиск медленных запросов в БД и медленных скриптов php, c оптимизацией системных настроек. И так до дех пор, пока не увидим что сервера больше не держат из за ресурсов. Проводим тест, сравниваем полученную цифру с исходной и радуемся. Ну и в конце мы запускаем тест на несколько часов, чтобы убедиться что сайт выдерживает продолжительную нагрузку.

В одной из следующих статей мы постараемся показать на примере как проходит оптимизация.

Автор: системный администратор компании Magvai69