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-yamlload_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) для достижения требуемого rpsssl:
включаем поддержку запросов по 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.netenabled: 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