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
1 |
# nano /etc/sysctl.conf |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
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 |
1 |
# sysctl -p |
Переменная была удален с версии ядра 4.12
1 |
tcp_tw_recycle |
Увеличение кол-ва открываемых файлов для текущего пользователя для текущей сессии
1 |
# ulimit -n 30000 |
Проверка кол-ва доступных/открываемых файлов для текущего пользователя в текущей сессии
1 |
# ulimit -n |
Если необходимо увеличить лимит на постоянной основе
1 |
# nano /etc/security/limits.d/20-nproc.conf |
1 |
soft nproc 30000 |
Если необходимо загружать результаты тестирования на ресурс Yandex.Overload
для удобного анализа/просмотра результатов тестирования, то регистрируемся на сайте https://overload.yandex.net и получаем токен (в правом верхнем углу My api token
)
Результаты будут доступны всем пользователям со всего мира, но без отображения сенситив данных(хоста, роутов/эндпонтов,которые были протестированы и т.д., т.е. без отображения содержимого конфигурационного файла load.yaml
, за исключением переменных job_name
и job_dsc
)
Создаем каталог, из которого будет запускать программу yandex-tank
1 |
# mkdir yandex-tank && cd yandex-tank |
В этом каталоге созадем файл с именем token.txt с содержимым токена, который был получен после регистрации на сайте https://overload.yandex.net
1 |
# cat token.txt |
1 |
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-процесса), тогда создаем и запускаем контейнер командой
1 |
# docker run -v $(pwd):/var/loadtest --net host -it direvius/yandex-tank |
Если необходимо предварительно (перед тестированием) выполнить какие-либо команды или
просто запускать тестирование отдельной командой в любой момент в уже запущенном контейнере,
тогда запустим контейнер переписывая его entrypoint с запуска yandex-tank утилиты на /bin/bash
1 |
# docker run -v $(pwd):/var/loadtest --name yandex-tank -it --net host --entrypoint /bin/bash direvius/yandex-tank |
После чего внутри контейнера выполним запуск тестирования с помощью команды
1 |
# yandex-tank -c load.yaml |
Процесс тестирования и результаты выполнения теста будут отображаться в консоли
Результат теста также будет автоматически загружен(если модуль overload настроен в файле load.yaml
) на сайт https://overload.yandex.net ссылка на который с корректным идентификатором будет отображена в консоли по окончанию тестирования
В данном случае https://overload.yandex.net/409226
4.Создание профиля тестирования/сценария нагрузки Yandex.Tank
Например,профиль нагрузочного тестирования имеет вид:
1 |
# cat load.yaml |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
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:
может быть const
, line
или 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
,
в котором содержатся все выполненные запросы со следующими полями
1 |
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
Просмотр доступных опций программы
1 |
# 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