Пример нагрузочного тестирования сайта с Yandex.Tank

Способов проверить работу сайта под нагрузкой много от самых примитивных утилит до целых систем. Я покажу конкретный пример нагрузочного тестирования сайта с помощью Yandex.Tank. Это бесплатный инструмент с очень большим функционалом и простой в использовании.

Введение

Для начала приведу несколько полезных ссылок на тему Yandex.Tank. Они все почему-то разрозненные и не связаны логически друг с другом. Функционал этого инструмента обширный, я же рассмотрю достаточно простой пример, поэтому точно пригодится документация.

Первым делом сходите на overload.yandex.net, зарегистрируйтесь там и получите токен. Он нам нужен будет далее, чтобы в удобном виде просматривать визуализацию результатов. Это не обязательное условие для совершения тестов и можно обойтись без него. Будет простенький вывод в консоли, с помощью которого можно оценить результат нагрузочного тестирования. Но с помощью модуля overload гораздо удобнее и нагляднее интерпретировать полученные данные.

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

При желании, вы можете установить Yandex.Tank из пакетов, либо запустить из исходников. Он написан на Python, так что к нему понадобится еще пачка модулей. Я же предпочитаю запускать его в Docker. Это в разы удобнее и быстрее.

Для начала установите себе докер, у меня есть статья по теме — установка docker на centos. После этого создаем директорию для данных танка и кладем туда конфиг нагрузочного теста для сайта.

token.txt	Текстовый файл с токеном от overload.yandex.net.
www.rambler.ru:443	Адрес сервера, который будем тестировать. Причем это не адрес сайта, так как это доменное имя просто резолвится в ip адрес. Можно задать сразу в виде ip.
Host: www.rambler.ru	Http заголовок, в котором мы передаем имя сайта, который будем нагружать.
/, /sport/	Урлы сайта, к которым по очереди будем обращаться. В данном случае это главная страница и страница /sport. Этот список может быть указан через текстовый файл. Подробности смотрите в документации.
line(5, 30, 1m)	Тип нагрузки. В данном случае это линейный рост запросов с 5 до 30 в течении одной минуты.
http(5xx,10%,5s)	Условие автоматической остановки теста. В данном случае тест завершится сам, если в течении 5 секунд будет 10% пятисотых ошибок.

Создадим текстовый файл с токеном:

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

Запуск нагрузки на сайта с помощью Yandex.Tank

Ждем окончания тестирования. Если укажите очень большую нагрузку, например в тысячи rps, можете повесить виртуалку или сайт (хе-хе). Вывод работы танка будет примерно такой.

В нагрузочном тестировании сайта нас в первую очередь интересует время отклика. Где его можно оценить, я выделил на скриншоте. После того, как завершится тест, в завершающем выводе работы контейнера будет ссылка на overload, где вы сможете посмотреть результат через браузер.

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

Например, на приведенном результате теста четко видно, как при приближении к 25-ти одновременным запросам начинает сильно расти время ответа сервера. На 20-ти запросах в 90-й перцентиль попадали все ответы менее 500 мс, а на 25-ти уже даже в 50-й перцентиль зашли ответы 750 мс.

Имеет смысл походить по вкладкам, там много другой полезной информации. С помощью данного тестирования вы сможете достаточно быстро определить предел производительности вашего железа.

Если хотите смоделировать более реальную нагрузку, а не синтетическую, то хорошенько поработайте над набором тестов и урлов. Можно очень гибко все это настроить. Например, добавить post запросы, где-то нарастающую нагрузку сделать, а где-то постоянную. Все это описано в документации. Там есть сильно навороченные примеры.

Заключение

С помощью Yandex.Tank вы без проблем можете положить неподготовленный сайт. Главное найти в нем самые медленные и нагруженные места (например поиск или большой каталог) А потом одновременно запустите тест из разных мест. А если еще и хорошенько автоматизируете это с помощью terraform и ansible, то совсем хорошо получится. Или плохо для владельца сайта. Правда это дороговато может стоить, есть способы подешевле. Но сейчас не будем об этом.

От такого рода «тестирования» достаточно просто защититься и стоит это делать всегда. Примеры защиты я подробно описывал в своих статьях — защита от ddos, защита от dos атак. В общем случае достаточно будет стандартных возможностей nginx, iptables и fail2ban. Удивительно, но очень много кто этого не делает. Я ради любопытства иногда клал очень неожиданные сайты. Но только в академических целях и на очень короткий период времени. Помним о карме и не вредим другим людям! Используем инструменты только во благо.

Installation¶

Docker container¶

Install docker and use direvius/yandex-tank (or, if you need jmeter, try direvius/yandex-tank:jmeter-latest ) container. Default entrypoint is /usr/local/bin/yandex-tank so you may just run it to start test:

• $(pwd):/var/loadtest — current directory mounted to /var/loadtest in container to pass data for test (config file, monitoring config, ammo, etc)
• tank will use load.yaml from current directory as default config, append -c custom-config-name.yaml to run with other config
• you may pass other additional parameters for tank in run command, just append it after image name
• $SSH_AUTH_SOCK:/ssh-agent — ssh agent socket mounted in order to provide use telegraf plugin (monitoring). It uses your ssh keys to remotely login to monitored hosts

If you want to do something in the container before running tank, you will need to change entrypoint:

Start test Within container with yandex-tank command:

Installation from PyPi¶

These are the packages that are required to build different python libraries. Install them with apt :

Update your pip:

Update/install your setuptools:

Install latest Yandex.Tank from master branch:

You’ll probably need Phantom load generator, so install it from our ppa:

Installation .deb packages¶

Deprecated. Deb packages aren’t renewed in PPA.

You should add proper repositories on Debian-based environment.

For instance, add following repos to sources.list :

Then update package list and install yandex-tank package:

© Copyright 2016, Yandex Revision 03aa0d9d .

sameoldmadness / README.md

Нагрузочное тестирование c Yandex.Tank и JMeter

На этой странице описывается процесс настройки нагрузочного тестирования внешних ресурсов.

Для тестирования поведения сервиса под нагрузкой используется утилита Yandex Tank.

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

В процессе стрельб все эти показатели отправляются в сервис Overload, который отображает эти метрики в удобном для восприятия виде. Напомню, что на этой странице мы говорим о тестировании внешних ресурсов. Если требуется пострелять по сервису Яндекса, стоит воспользоваться документацией Qloud.

Последний сервис, о котором стоит упомянуть – JMeter. Он может быть использован в качестве альтернативного генератора нагрузки для танка. Такая возможность пригодится, если в сценариях тестирования нужно эмулировать пользовательские сессий либо другие сложные сценарии, которые танк из коробки не поддерживает.

Рекомендуемый способ – запустить танк в докер-контейнере.

Финальная команда запуска может выглядеть так:

• Для использования JMeter понадобится Java. Если вам не по душе ставить заново при каждом запуске контейнера, лучше подготовить свой образ.
• Танку в паре с JMeter не хватит стандартных 2GB памяти, лучше сразу удвоить объём выделяемой памяти. В Docker for Mac этот параметр есть в настройках приложения.

Основной файл конфигурации – load.yaml.

Документация иногда продолжает ссылать на старый формат – ini, но верить ей не стоит – парсер ini-конфигов сломан, и ряд опций в этом формате задать просто не получится.

Если нужный вам параметр представлен в только в ini-формате, узнать его название в формате yaml можно из исходников. Например, вот пример описания схемы секции плагина JMeter.

Пример простейшего конфига.

Здесь следует обратить внимание на следующие поля:

• address – домен (или ip-адрес) и порт цели. Если нужна поддержка https, используйте параметр ssl.
• ammofile – файл с патронами (запросами к цели). Есть несколько способов задавать патроны.
• load_profile – расписание. Тут задаётся нагрузка и продолжительность стрельб.
• telegraf – мониторинг, о нём отдельно поговорим ниже.
• uploader – агрегатор, о нём – тоже поговорим.

Достаточно выполнить команду

Для настроки Телеграфа нужно настроить ssh-соединение с целью. Для этого публичный ключ танка нужно добавить на целевой сервис.

Далее нужно сконфигурировать секцию в основном конфиге load.yaml .

Как видно, для мониторинга нужен отдельный конфиг – monitoring.xml . В простейшем виде он выглядит так.

Для начала нужно получить токен.

Для этого нужно авторизоваться на сайте, кликнуть на аватарку и скопировать токен. Затем нужно создать файл token.txt и положить туда токен.

Простейший конфиг выглядит так.

Ссылка на результаты отобразится в терминале при запуске стрельб.

Он более сложен в настройке, чем дефолтный генератор – phantom, но в тоже время более гибок. Мы будем использовать его для нетривиальных сценариев запросов – например, для эмуляции пользовательских сессий, когда запросы от одного пользователя должны выполнятся последовательно.

В контейнере должна быть установлена Java. Можно подготовить собственный образ либо установить пакет вручную.

Теперь нужно скачать архив с бинарниками и распаковать его.

Также может потребоваться установить дополнительные плагины. Для этого откройте JMeter локально, через графический интерфейс установите плагин plugin-manager и откройте тестовый сценарий. Вам будет предложено установить недостающие плагины. После установки папку ext можно будет перенести в контейнер.

Конфигурация JMeter разнесена между тестовым сценарием *.jmx и конфигом танка load.yaml .

Секция JMeter load.yaml может выглядеть так.

variables – пользовательские переменные (аналог переменных окружения), которые будут проброшены в тестовый сценарий.

Описание принципов создания тестового сценария выходит за рамки данной статьи.

Яндекс.Танк и автоматизация нагрузочного тестирования

В ходе тестирования некоторых продуктов компании Positive Technologies возникла необходимость проведения быстрых стресс-тестов одного веб-сервиса. Эти тесты должны были быть простыми и быстрыми в разработке, нетребовательными к аппаратным ресурсам и одновременно с этим давать значительную нагрузку однотипными HTTP-запросами, а также предоставлять статистические данные для анализа системы под нагрузкой.

В ходе тестирования некоторых продуктов компании Positive Technologies возникла необходимость проведения быстрых стресс-тестов одного веб-сервиса. Эти тесты должны были быть простыми и быстрыми в разработке, нетребовательными к аппаратным ресурсам и одновременно с этим давать значительную нагрузку однотипными HTTP-запросами, а также предоставлять статистические данные для анализа системы под нагрузкой.

Для их реализации мы исследовали и опробовали некоторое количество инструментов, среди которых были Apache JMeter и написанный нами на Python скрипт LogSniper, который выполнял реплей заранее подготовленных серверных логов с HTTP-запросами на цель.

От использования JMeter было решено отказаться из-за значительной сложности подготовки и проведения тестов, высоких требований к производительности нагрузочного стенда и довольно малых мощностей нагрузки, хотя эти недостатки и компенсировались высокой информативностью собираемой статистики. LogSniper был отклонен из-за малой мощности генерируемой нагрузки и здесь даже простота подготовки нагрузочных HTTP-пакетов не смогла перевесить. Другие известные инструменты нам по тем или иным причинам тоже не подошли.

В итоге мы остановились на инструменте Яндекс.Танк, о котором узнали, побывав на конференции YAC-2013 и пообщавшись со специалистами Яндекса. Этот инструмент полностью отвечал всем нашим требованиям к простоте подготовки теста и к генерируемой нагрузке.

Что это

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

В процессе своей работы Танк сохраняет полученные результаты в обычных текстовых журналах, сгруппированных по директориям для отдельных тестов. Во время теста специальный модуль организует вывод результатов в консольный интерфейс в виде таблиц. Одновременно запускается локальный веб-сервер, позволяющий видеть те же самые результаты на информативных графиках. По окончании теста возможно автоматическое сохранение результатов на сервисеLoadosophia.org. Также имеется модуль загрузки результатов в хранилище Graphite.

Некоторые полезные ссылки:

• код проекта на GitHub;
• официальная документация по настройке и использованию инструмента;
• информация о модулях Танка в wiki разработчиков;
• презентация об истории возникновения инструмента;
• история возникновения сервиса нагрузочного тестирования в Яндексе и разработки Танка;
• Яндекс-клуб, посвященный вопросам использования инструмента.

Сегодня мы не будем подробно останавливаться на установке и настройке Танка, поскольку эту информацию легко найти в сети, а сразу перейдем к описанию своего опыта его использования.

Сравнение производительности двух аналогичных веб-сервисов

В ходе работы нам потребовалось сравнить характеристики двух веб-сервисов, работу которых можно примерно описать как «прозрачные HTTP-прокси, перенаправляющие входящие запросы на backend-приложение».

Общую схему работы можно изобразить следующим образом:

На стенде с Танком использовался генератор нагрузки phantom с включенным монитором производительности.

В качестве стенда web-proxy на схеме использовались два тестируемых веб-сервиса, с которых при помощи агента Танка снимались показатели производительности. Условно назовем их Эталонный веб-сервис и Испытуемый веб-сервис. Нам требовалось понять, соответствует ли производительность испытуемого веб-сервиса эталонному.

Для backend использовалось небольшое веб-приложение, запущенное под Nginx и возвращающее одну простую HTML-страничку.

Выявленные ограничения

Перед началом работ мы собрали информацию об ограничениях виртуальных стендов, на которых была построена вся тестовая инфраструктура.

Характеристики стенда backend-приложения:

• 8 vCPU, 4 GB, 10 Gb/s,
• веб-сервер Nginx.

Максимальная отдача сервера, которой удалось добиться, составила

25 000 http-rps, но и при нагрузке выше 25k http-rps работа стенда не была нарушена.

Стенд Танка с характеристиками 16 vCPU, 8 GB, 10 Gb/s позволил реализовать нагрузку до 300 000 http-rps.

Пропускная способность виртуальной среды ESXi, определенная с помощью Iperf, составила 8 Gb/s в одну сторону, 4 Gb/s при двухсторонней нагрузке между двумя виртуальными машинами.

Метрики и критерии сравнения

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

• http_rps_out — значение http-rps, отправляемое с Танка на веб-приложение,
• http_rps_in — значение http-rps, принимаемое на Танке со стороны веб-приложения,
• http_request_size — размер http-запроса в байтах,
• send_requests — количество отправленных HTTP-запросов,
• bs_out — bytes per seconds, байт в секунду — параметр определяет скорость отправки данных с Танка,
• bs_in — значение bs, отправляемое с веб-приложения в сторону Танка,
• test_time — время теста в секундах,
• response_time_med — среднее время, в которое укладывается 90% всех ответов.

Зная число HTTP-запросов и их размер, получаем, что bs и http-rps связаны по формуле: bs = http_rps * http_request_size.

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

1. За все время теста значение параметра «время, в которое укладывается 90% ответов» у испытуемого веб-сервиса должно быть не больше, чем у эталонного веб-сервиса.
2. На отрезке возрастания нагрузки на очередные 1000 http-rps значение параметра «время, в которое укладывается 90% ответов» у испытуемого веб-сервиса должно быть не больше, чем у эталонного веб-сервиса.
3. За все время теста общее количество правильно обработанных запросов у испытуемого веб-сервиса должно быть не меньше, чем у эталонного веб-сервиса.

Аналогичным образом можно определить иные критерии нагрузочных тестов для любых проектов.

Тестовые HTTP-запросы

Для одного из профилей нагрузочных тестов нам требовалось создать смешанный HTTP-трафик из GET- и POST-запросов с линейным возрастанием нагрузки до 10k http-rps в течение 10 минут.

POST /loadtest/index.php HTTP/1.1
X-Sniffer-Forwarded-For: yandex-tank-example-domain.ptsecurity.ru
Host: backend-example-domain.ptsecurity.ru
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Content-Length: 32

POST /loadtest/index.php HTTP/1.1
X-Sniffer-Forwarded-For: yandex-tank-example-domain.ptsecurity.ru
Content-Type: multipart/form-data; boundary=validFile
Host: backend-example-domain.ptsecurity.ru
User-Agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Content-Length: 150

—validFile
Content-Disposition: form-data; name=»login»; filename=»validFile.txt»
Content-Type: text/plain

Valid file content
—validFile—

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

Сбор данных и анализ результатов

После подготовки запросов мы просто запустили Танк стандартным образом и выполнили нагрузочный тест со смешанным трафиком для обоих тестируемых веб-сервисов.

Результаты для эталонного веб-сервиса

Информация веб-монитора Танка:

Информация консоли Танка:

Результаты для испытуемого веб-сервиса

Информация веб-монитора Танка:

Информация консоли Танка:

Даже судя по графикам, испытуемый сервис показывал результаты не хуже, чем эталонный. Проверив все три формально определенных выше критерия, мы в этом убедились.

1. Испытуемый сервис удовлетворяет первому критерию, так как для 90% запросов среднее время ответов для испытуемого сервиса не превышало такой же показатель для эталонного сервиса.
2. Требование второго критерия выполнялось для каждого этапа нагрузки.
3. Судя по анализу статус-кодов ответов, записанных в журналы Танка, испытуемый веб-сервис принял и корректно обработал запросов больше, чем эталонный веб-сервис.

Выводы

По результатам работы с Яндекс.Танком можно с полной ответственностью заявить, что этот инструмент отлично подходит в тех случаях, когда требуется быстро провести нагрузочное тестирование веб-приложений без их сложной подготовки и при этом получить множество полезных статистических данных для анализа производительности.

Кроме того, он хорошо внедряется в имеющиеся системы автоматизации. Например, для упрощения работы со стендом Танка — управления, запуска, подготовки патронов для лент, контроля за процессом тестирования и сбором результатов — мы без особых усилий написали класс-обвязку на Python, который подключается к стенду по SSH и выполняет все перечисленные действия. Затем этот класс был встроен в нашу существующую систему авто-тестирования.

Дополнительно вы можете посмотреть, как подключить и использовать высокопроизводительную систему Graphit для анализа большого числа графиков (о ней рассказывалось в одной из презентаций на конференции YAC-2013). Ее также можно приспособить для нужд нагрузочного тестирования с использованием Яндекс.Танка.

Выражаю благодарность моему коллеге Олегу Каштанову за техническую поддержку.