Нагрузочное тестирование с помощью Yandex Tank

1.Общее описание, структурная схема и жизненный цикл тестирования Yandex.Tank
2.Базовая пред подготовка сервера с Yandex.Tank
3.Установка Yandex.Tank
4.Создание профиля тестирования/сценария нагрузки для Yandex.Tank

1.Общее описание, структурная схема и жизненный цикл тестирования Yandex.Tank

Яндекс.Танк — инструмент для проведения нагрузочного тестирования, разрабатываемый в компании Яндекс и распространяемый под лицензией LGPL.
В основе инструмента лежит высокопроизводительный асинхронный генератор нагрузки phantom,
который был изначально переделан из одноимённого веб-сервера, который «научили» работать в режиме клиента.
При помощи phantom(используется в качестве дефолтного генератора нагрузки) возможно генерировать десятки и сотни тысяч http-запросов в секунду.

В процессе своей работы Яндекс.Танк сохраняет полученные результаты в обычных текстовых лог-файлах,сгруппированных по директориям для отдельных тестов.
В течение теста специальный модуль организует вывод результатов в табличном виде в консольный интерфейс.
По окончании теста возможно автоматическое сохранение результатов на
внешние сервисы (Graphite, InfluxDB, Yandex.Overload)

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

В качестве альтернативного генератора нагрузки для танка может использоваться jMeter(кроме этого поддерживается еще несколько других генераторов нагрузки)
Такая возможность пригодится, если в сценариях тестирования нужно эмулировать пользовательские сессий либо другие сложные сценарии, которые танк из коробки не поддерживает.

Основные компоненты Yandex Tank
Ядро — основные этапы подготовки, настройки, выполнения теста. Хранение артефактов. Управление плагинами/модулями.
Генераторы нагрузки — модули, которые используют и контролируют генераторы нагрузки(Phantom, Jmeter, BFG, Pandora)
Загрузчики артефактов — модули, которые загружают артефакты во внешние хранилища и сервисы(Graphite, InfluxDB, Yandex.Overload)
Удобные инструменты/модули/плагины — инструменты мониторинга(Telegraf), онлайн-экран консоли(Console on-line screen), автоостановки(Auto-stop), аггрегатор(Aggregator), ShellExec, Resource Check и так далее.

Архитектура и взаимодействия модулей с ядром Yandex.Tank
https://yandextank.readthedocs.io/en/latest/core_and_modules.html


2.Базовая пред подготовка сервера с Yandex.Tank

Базовый тюнинг/оптимизация операционной системы, на которой будет запускаться Yandex.Tank
https://yandextank.readthedocs.io/en/latest/generator_tuning.html

Оптимизация cетевых настроек переменных ядра(системные лимиты) на сервере, на котором запускается Yandex.Tank

# nano /etc/sysctl.conf
net.ipv4.tcp_max_tw_buckets = 65536
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_max_syn_backlog = 131072
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 8
net.ipv4.tcp_rmem = 16384 174760 349520
net.ipv4.tcp_wmem = 16384 131072 262144
net.ipv4.tcp_mem = 262144 524288 1048576
net.ipv4.tcp_max_orphans = 65536
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_low_latency = 1
net.ipv4.tcp_syncookies = 0
net.netfilter.nf_conntrack_max = 1048576
# sysctl -p

Переменная была удален с версии ядра 4.12

tcp_tw_recycle

Увеличение кол-ва открываемых файлов для текущего пользователя для текущей сессии

# ulimit -n 30000

Проверка кол-ва доступных/открываемых файлов для текущего пользователя в текущей сессии

# ulimit -n

Если необходимо увеличить лимит на постоянной основе

# nano /etc/security/limits.d/20-nproc.conf
soft nproc 30000

Если необходимо загружать результаты тестирования на ресурс Yandex.Overload
для удобного анализа/просмотра результатов тестирования, то регистрируемся на сайте https://overload.yandex.net и получаем токен (в правом верхнем углу My api token)
Результаты будут доступны всем пользователям со всего мира, но без отображения сенситив данных(хоста,  роутов/эндпонтов,которые были протестированы и т.д., т.е. без отображения содержимого конфигурационного файла load.yaml, за исключением переменных job_name и job_dsc)

Создаем каталог, из которого будет запускать программу yandex-tank

# mkdir yandex-tank && cd yandex-tank

В этом каталоге созадем файл с именем token.txt с содержимым токена, который был получен после регистрации на сайте https://overload.yandex.net

# cat token.txt
123456789…

В этом же каталоге создаем файл/профиль нагрузочного тестирования с именем load.yaml


3.Установка Yandex.Tank

https://yandextank.readthedocs.io/en/latest/install.html
YandexTank можно установить несколькими способами:
1. Запускать в Docker-контейнере (наиболее простой способ, будем использовать его)
2. Установить из python-модулей через pip3 установщик модулей в python
3. Установить из системных пакетов для deb-based операционных систем (с добавлением дополнительного PPA-репозитария)
Однако deb-пакеты в таком PPA-репозитарии не обновляются, поэтому этот способ считается устаревшим

Если необходимо запускать тестирование при старте контейнера(например,для ci/cd-процесса), тогда создаем и запускаем контейнер командой

# docker run -v $(pwd):/var/loadtest --net host -it direvius/yandex-tank

Если необходимо предварительно (перед тестированием) выполнить какие-либо команды или
просто запускать тестирование отдельной командой в любой момент в уже запущенном контейнере,
тогда запустим контейнер переписывая его entrypoint с запуска yandex-tank утилиты на /bin/bash

# docker run -v $(pwd):/var/loadtest --name yandex-tank -it --net host --entrypoint /bin/bash direvius/yandex-tank

После чего внутри контейнера выполним запуск тестирования с помощью команды

# yandex-tank -c load.yaml

Процесс тестирования и результаты выполнения теста будут отображаться в консоли

Результат теста также будет автоматически загружен(если модуль overload настроен в файле load.yaml) на сайт https://overload.yandex.net ссылка на который с корректным идентификатором будет отображена в консоли по окончанию тестирования
В данном случае https://overload.yandex.net/409226

4.Создание профиля тестирования/сценария нагрузки Yandex.Tank

Например,профиль нагрузочного тестирования имеет вид:

# cat load.yaml
phantom:
  address: mydomain.com:443
  header_http: "1.1"
  headers:
    - "[Host: mydomain.com]"
    - "[User-Agent: Tank]"
  uris:
    - /route1
    - /route2
    - /route3
    - /route4
    - /route5
    - /route6
  load_profile:
    load_type: rps
    schedule: line(40, 50, 1m) const(50,2m)
  instances: 1000
  ssl: true
console:
  enabled: true
telegraf:
  enabled: false
autostop:
  autostop:
    - http(5xx,10%,5s)
    - time(10s,15s)
    #- net(110,5%,10s)
overload:
  enabled: true
  package: yandextank.plugins.DataUploader
  token_file: "token.txt"
  job_name: GET-requests
  job_dsc: line(40, 50, 1m) const(50,2m) | http(5xx,10%,5s) time(10,15) | instances 1000

Используем несколько(в данном случае 6 эндпонитов/роутов, на которые будем отправлять запросы)

phantom — используется в качестве генератора нагрузки

address: адрес и порт тестируемого хоста
header_http: версия HTTP для тестов, зададим 1.1, что бы использовать одно соединение на запросы, а не открывать новое каждый раз. Подробнее
headers: заголовки, передаваемые на тестируемый сервер
uris: список URI, к которым выполняем запросы
В блок uris можно передавать только GET-запросы. Для передачи POST-запросов используем опцию
ammo_type: uripost
и выключаем/комментируем опцию uris
Для GET-запросов список URI и заголовков можно указывать, как в основном конфигурационном файле load.yaml с помощью опции uris:
а также и в отдельном файле используя вместо uris опцию
ammo_type: uri в файле load.yaml
и создав файл ammo.txt с нужными URI и заголовками.
https://yandextank.readthedocs.io/en/latest/tutorial.html#uri-style-uris-in-file
https://yandextank.readthedocs.io/en/latest/tutorial.html#uri-style-uris-in-load-yaml
load_profile:
load_type: может быть rps или instances
rps: requests per second — указываем желаемое количество запросов в секунду
instances: указываем желаемое количество активных тредов, которые будут генерировать столько rps, сколько смогут, Подробнее
schedule: может быть constline или step (или несколько вместе) — определяет характер генерируемой нагрузки, Подробнее
line: указывается в виде (a,b,dur), где a — начальное кол-во rps, b — конечное, dur — время для выполнение тестирования, в течении которого значение будет линейно увеличиваться от a до b
В данном случае стартуем с 40 запросов/секунду и в течение 60 секунд увеличиваем до 50 запросов/секунду
const: указывается в виде (load,dur), где load — кол-во rps, dur — время для выполнение тестирования
В данном случае выполняем 50 запросов в секунду течении 120 секунд
step: указывается в виде (a,b,step,dur), где a — начальное кол-во rps, b — конечное, step — на сколько rps увеличивать, dur — время между каждым step
line и cost можно комбинировать, а step -нельзя комбинировать
instances: количество активных тредов, которые будут генерировать заявленную нагрузку( по умолчанию равно 1000) для достижения требуемого rps
ssl: включаем поддержку запросов по HTTPS (не забываем указать 443 в address)
console: включаем вывод результатов в консоль
telegraf: агент мониторинга для сбора метрик с тестируемого хоста
autostop: автоматическая остановка теста при возникновении каких-либо событий.
В данном случае остановка теста при выполнении любого из условий:
http(5xx,10%,5s) — кол-во HTTP-ответов в каждую секунду (подсчет производится именно каждую секунду) со статусом кода 5xx в течение 5 секунд больше или равно 10% от общего кол-ва ответов
time(10s,15s) — среднее время ответа превышает 10 секунд в течение последних 15 секунд тестирования
net(110,5%,10s) — кол-во сетевых ответов в каждую секунду с кодом ответа 110(Connection timed out) превышает 5% от общего кол-ва сетевых ответов в течение 10 секунд
Данный тригер отключен(т.к. он закомментирован, но такая возможность поддерживается)
Более подробно про условия авто остановки теста

overload: — использования модуля overload для публикации результатов тестирования на сайте https://overload.yandex.net
enabled: true — включаем этот модуль
token_file: — указываем файл содержащий токен
job_name и job_dsc — описание и имя теста(удобно задать значения этих параметров здесь, чтобы потом не задавать руками на сайте)

Модуль: telegraf
позволяет мониторить удаленный сервер и отображать снимаемые с него метрики в консоле во время тестирования,
а также отправлять их на Yandex.Overload
Это удобно для последующего анализа запросов.
Подключается через SSH к удаленному целевому хосту, запускает на нем своего агента и снимает метрики использования ресурсов целевым хостом(процессорного времени, памяти, диска и т.д.)

Во время тестирования целевого хоста yandex-tank создает каталог logs
в текущем каталоге и в нем много различных файлов/логов в том числе файлы логов, файлы конфигурации, файлы отчетов в том числе и файл phout.txt,
в котором содержатся все выполненные запросы со следующими полями

time, tag, interval_real, connect_time, send_time, latency, receive_time, interval_event, size_out, size_in, net_code proto_code

Этот файл может быть загружен в Excel для дальнейшего анализа

Описание поддерживаемых модулей и опций для их настройки
https://yandextank.readthedocs.io/en/latest/core_and_modules.html

Просмотр доступных опций программы

# yandex-tank -h

Источник:
https://yandextank.readthedocs.io/en/latest/index.html
https://rtfm.co.ua/yandex-tank-nagruzochnoe-testirovanie
https://serveradmin.ru/primer-nagruzochnogo-testirovaniya-sajta-s-yandex-tank
https://gist.github.com/sameoldmadness/9abeef4c2125bc760ba2f09ee1150330
https://medium.com/@k0st1an
https://forworktests.blogspot.com/2013/11/yandex-tank.html

Was this helpful?

0 / 0