Пример нагрузочного тестирования сайта с Yandex.Tank
Способов проверить работу сайта под нагрузкой много от самых примитивных утилит до целых систем. Я покажу конкретный пример нагрузочного тестирования сайта с помощью Yandex.Tank. Это бесплатный инструмент с очень большим функционалом и простой в использовании.
Введение
Для начала приведу несколько полезных ссылок на тему Yandex.Tank. Они все почему-то разрозненные и не связаны логически друг с другом. Функционал этого инструмента обширный, я же рассмотрю достаточно простой пример, поэтому точно пригодится документация.
Первым делом сходите на overload.yandex.net, зарегистрируйтесь там и получите токен. Он нам нужен будет далее, чтобы в удобном виде просматривать визуализацию результатов. Это не обязательное условие для совершения тестов и можно обойтись без него. Будет простенький вывод в консоли, с помощью которого можно оценить результат нагрузочного тестирования. Но с помощью модуля overload гораздо удобнее и нагляднее интерпретировать полученные данные.
Установка Yandex.Tank
При желании, вы можете установить Yandex.Tank из пакетов, либо запустить из исходников. Он написан на Python, так что к нему понадобится еще пачка модулей. Я же предпочитаю запускать его в Docker. Это в разы удобнее и быстрее.
| 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
В нагрузочном тестировании сайта нас в первую очередь интересует время отклика. Где его можно оценить, я выделил на скриншоте. После того, как завершится тест, в завершающем выводе работы контейнера будет ссылка на overload, где вы сможете посмотреть результат через браузер.
Пройдя по ней вы сможете более детально изучить поведение сайта под нагрузкой.
Например, на приведенном результате теста четко видно, как при приближении к 25-ти одновременным запросам начинает сильно расти время ответа сервера. На 20-ти запросах в 90-й перцентиль попадали все ответы менее 500 мс, а на 25-ти уже даже в 50-й перцентиль зашли ответы 750 мс.
Имеет смысл походить по вкладкам, там много другой полезной информации. С помощью данного тестирования вы сможете достаточно быстро определить предел производительности вашего железа.
Если хотите смоделировать более реальную нагрузку, а не синтетическую, то хорошенько поработайте над набором тестов и урлов. Можно очень гибко все это настроить. Например, добавить post запросы, где-то нарастающую нагрузку сделать, а где-то постоянную. Все это описано в документации. Там есть сильно навороченные примеры.
Заключение
С помощью Yandex.Tank вы без проблем можете положить неподготовленный сайт. Главное найти в нем самые медленные и нагруженные места (например поиск или большой каталог) А потом одновременно запустите тест из разных мест. А если еще и хорошенько автоматизируете это с помощью terraform и ansible, то совсем хорошо получится. Или плохо для владельца сайта. Правда это дороговато может стоить, есть способы подешевле. Но сейчас не будем об этом.
Яндекс.Танк и автоматизация нагрузочного тестирования
В ходе тестирования некоторых продуктов компании 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.
Некоторые полезные ссылки:
Сравнение производительности двух аналогичных веб-сервисов
В ходе работы нам потребовалось сравнить характеристики двух веб-сервисов, работу которых можно примерно описать как «прозрачные HTTP-прокси, перенаправляющие входящие запросы на backend-приложение».
Общую схему работы можно изобразить следующим образом:
На стенде с Танком использовался генератор нагрузки phantom с включенным монитором производительности.
В качестве стенда web-proxy на схеме использовались два тестируемых веб-сервиса, с которых при помощи агента Танка снимались показатели производительности. Условно назовем их Эталонный веб-сервис и Испытуемый веб-сервис. Нам требовалось понять, соответствует ли производительность испытуемого веб-сервиса эталонному.
Для backend использовалось небольшое веб-приложение, запущенное под Nginx и возвращающее одну простую HTML-страничку.
Выявленные ограничения
Перед началом работ мы собрали информацию об ограничениях виртуальных стендов, на которых была построена вся тестовая инфраструктура.
Характеристики стенда backend-приложения:
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-запросы
Для одного из профилей нагрузочных тестов нам требовалось создать смешанный HTTP-трафик из GET- и POST-запросов с линейным возрастанием нагрузки до 10k http-rps в течение 10 минут.
Чтобы упростить подготовку патрона для такого смешанного трафика, мы сделали скрипты, аналогичные perl-скриптам, предлагаемым на форуме.
Сбор данных и анализ результатов
После подготовки запросов мы просто запустили Танк стандартным образом и выполнили нагрузочный тест со смешанным трафиком для обоих тестируемых веб-сервисов.
Результаты для эталонного веб-сервиса
Информация веб-монитора Танка:
Информация консоли Танка:
Результаты для испытуемого веб-сервиса
Информация веб-монитора Танка:
Информация консоли Танка:
Даже судя по графикам, испытуемый сервис показывал результаты не хуже, чем эталонный. Проверив все три формально определенных выше критерия, мы в этом убедились.
Выводы
По результатам работы с Яндекс.Танком можно с полной ответственностью заявить, что этот инструмент отлично подходит в тех случаях, когда требуется быстро провести нагрузочное тестирование веб-приложений без их сложной подготовки и при этом получить множество полезных статистических данных для анализа производительности.
Кроме того, он хорошо внедряется в имеющиеся системы автоматизации. Например, для упрощения работы со стендом Танка — управления, запуска, подготовки патронов для лент, контроля за процессом тестирования и сбором результатов — мы без особых усилий написали класс-обвязку на Python, который подключается к стенду по SSH и выполняет все перечисленные действия. Затем этот класс был встроен в нашу существующую систему авто-тестирования.
Дополнительно вы можете посмотреть, как подключить и использовать высокопроизводительную систему Graphit для анализа большого числа графиков (о ней рассказывалось в одной из презентаций на конференции YAC-2013). Ее также можно приспособить для нужд нагрузочного тестирования с использованием Яндекс.Танка.
Выражаю благодарность моему коллеге Олегу Каштанову за техническую поддержку.
Наши танки. История нагрузочного тестирования в Яндексе
Я хочу сегодня вспомнить о том, как нагрузочное тестирование в Яндексе появилось, развивалось и устроено сейчас.
Кстати, если вам понравится этот рассказ, приходите на Тестовую среду в нашем питерском офисе 30 ноября (зарегистрироваться), – там я расскажу больше об игровых механиках в тестировании и с удовольствием вживую с вами поговорю. Итак.
В 2005-2006 годах часть не поисковой инфраструктуры Яндекса стала испытывать нагрузки растущего как на дрожжах Рунета. Появилась необходимость тестировать производительность смежных с поиском сервисов, в первую очередь — баннерную крутилку. Тимур Хайруллин, на тот момент руководивший нагрузочным тестированием, озадачился поиском подходящего инструмента.
Но существующие в то время открытые решения были либо очень примитивны (ab/siege), либо недостаточно производительны (jmeter). Из коммерческих утилит выделялся HP Load Runner, но дороговизна лицензий и завязка на проприетарный софт нас не обрадовала. Поэтому Тимур вместе с разработчиком высокопроизводительного веб-сервера phantom Женей Мамчицем придумали хитрый трюк: они научили сервер работать в режиме клиента. Так получился модуль phantom-benchmark. Сам код фантома теперь открыт и его можно скачать отсюда, а рассказ про фантом можно посмотреть видео с презентации здесь.
Тогда Phantom был очень прост, умел измерять только максимальную производительность сервера, а мы могли лишь ограничивать количество потоков. Но уже в то время наша утилита была на голову производительней аналогов. Поэтому за нагрузочным тестированием к нам стали обращаться все чаще и все больше сервисов. С 2006 до 2009 года команда нагрузочного тестирования разрослась до десяти человек. К нам очень быстро прикрепилось название «танкисты», которые заряжают «ленты» с «патронами» и “стреляют” из «танков» по «мишеням». Танковая тематика до сих пор с нами. Для экономии ресурсов мы создали специальный «полигон» или «курятник», где держали виртуальные машины для нагрузочного тестирования. Платформа виртуализации в то время была на openvz, а сейчас мы полностью перешли на lxc из-за лучшей поддержки новых ядер и дистрибутивов ubuntu server. Респект сообществу lxc!
Параллельно с приходящими сервисами и ростом популярности нагрузочного тестирования, а точнее, с ростом самосознания команд сервисов, приходило понимание ограничения возможностей инструмента.
При содействии разработчиков и под руководством «танкиста» Андрея baabaka Кузьмичева мы стали развивать phantom в настоящий фреймворк для поддержки нагрузочного тестирования — Лунапарк. Ранее из-за плохой организации отчетов результаты складировались бессистемно — в Wiki, JIRA, почту и пр. Это было очень неудобно, мы вложили много труда в это больное место и постепенно у нас появился настоящий веб-интерфейс с дашбордом и графиками, где все тесты были провязаны с тикетами в JIRA, все отчеты наконец получили единообразие и понятный дизайн. Веб-интерфейс научился отображать процентили, тайминги, средние времена, коды ответа, объем получаемых и передаваемых данных и еще около 30 различных графиков и таблиц. Помимо этого Лунапарк был провязан с почтой, джаббером и другими сервисами. Изменения не обошли стороной и сам генератор нагрузки Phantom — он научился делать очень многое из того, чего не умел раньше. Например, подавать запросы по расписанию — линейно, ступенчато, снижать нагрузку и даже(!) подавать нулевую и дробную нагрузку. В консольный вывод добавился агрегационный вывод с процентилями, мониторинг объема данных, ошибок, ответов. Так выглядел консольный вывод образца 2009 года.
Постепенно пришло понимание, что нужно не только постоянно тестировать некоторые сервисы, но и сопровождать их из года в год от релиза к релизу, а также уметь сравнивать тесты между собой. Так появились важные для работы нагрузочного тестировщика страницы Лунапарка: сравнение тестов и регрессия. Так выглядели их первые версии.
Тестировщик, разработчик или менеджер в любой момент мог узнать, как развивается продукт с точки зрения производительности. Сейчас мы работаем над улучшением и выносом этих страниц во главу фреймворка. На текущем этапе развития нам наиболее важны не единичные тесты, а тренды производительности.
В 2011 году произошло важное событие — мы стали первой командой в Яндексе, запустившей настоящую геймификацию рабочего процесса, о которой у меня будет отдельный доклад на Тестовой среде. Такое даже сейчас редко встречается и в самых продвинутых IT-компаниях. На странице Лунапарка мы разместили «Зал Cлавы» и очень гордимся этой частью фреймворка. За конкретный тест можно сказать нагрузочному тестировщику настоящее дружеское «Спасибо!». Каждый тестер получает различные бэйджи за то или иное событие, становится «командиром танка» (а-ля мэром в Форскверике) и даже “звание”, которое выдается за число проведенных тестов. Среди рутинной работы любая ачивка или спасибка на вес золота. Это очень здорово мотивирует.
2011 год мы считаем переломным в нашем нагрузочном тестировании. Команду разработки возглавил Андрей undera Похилько. Сообщество тестеров знает его как разработчика замечательных плагинов для Jmeter. Андрей принес свежие идеи и подходы, которые сейчас очень помогают в работе.
Во-первых, мы поняли, что развивать инструмент в старой парадигме «некогда объяснять, кодируй» не получается, и перешли на модульную парадигму разработки, где большой монолит разбивается на компоненты и развивается отдельным частями, не создавая угрозу всему проекту. Во-вторых, так как заказы на нагрузочное тестирование стали поступать от сервисов, которым http-трафик был не интересен, нам понадобился инструмент, которым можно было бы тестировать SMTP/POP3/FTP/DNS и прочие протоколы. Писать phantom-протоколеры на каждый такой сервис нам показалось дорого, и мы решили встроить в Лунапарк обычный Jmeter. Тем самым небольшими усилиями мы научились поддерживать в нагрузочном тестировании несколько десятков новых протоколов. Встраивание помогло нам оставить стандартный вебинтерфейс без перехода на Jmeter GUI. Помимо поддержки Jmeter наш танк со временем научился поддерживать SSL, IPv6, UDP, elliptics, “мультитесты” в несколько адресов с одного генератора, подачу нагрузки в несколько миллионов rps с распределенных генераторов и многое другое.
В определенный момент заказов на нагрузочное тестирование повалило так много, что нам стало очевидно: мы не сможем удваивать штат каждый год без снятия рутинных и регрессионных тестов с нагрузочного тестировщика. Для решения этой задачи мы проанализировали всю нашу текущую каждодневную работу, и оказалось, что к сервисам нужно подходить с разной степенью глубины тестирования. Мы придумали следующую схему работы:
Для анализа по желанию можно включать дополнительные графики, например, времена ответа.
HTTP и сетевые ошибки:
Времена на разных стадиях взаимодействия и потоки:
Для регрессионных тестов, или для тестов, приемка результатов которых проводится разработчиками, либо администраторами, мы сделали так называемые автоматические и полуавтоматические тесты. Про это нужно рассказать отдельно.
В конце 2011 мы поняли, что по сути все операции теста могут делаться скриптами, вызовами, или, проще говоря, каким-то исполняющим механизмом. Идеологически ближе всего к такой деятельности стоят CI фреймворки, которые умеют собирать проекты, запускать набор тестов, уведомлять о событиях и выносить вердикт о прохождении. Мы посмотрели на варианты этих инструментов и обнаружили, что открытых фреймворков не так много. Jenkins показался нам наиболее удобным для расширения функциональности с помощью плагинов и, потестировав его рядом с Лунапарком, внедрили его в тестирование. С помощью внешних вызовов к специальному API и встроенного планировщика мы смогли переложить всю рутинную работу тестеровщика на Jenkins. Разработчики получили заветную кнопку «Протестировать мой сервис сейчас!», нагрузочники получили десятки, а то и сотни тестов в день без их участия, менеджеры и системные администраторы получили регрессионные графики производительности от билда к билду. На данный момент автоматические тесты составляют около 70% от всего потока, и этот показатель постоянно растет. Это экономит нам десятки человек в штате и позволяет сконцентрировать интеллект тестера на ручных и исследовательских тестах.
Внимательный читатель заметит, что постепенно Лунапарк стал представлять собой раздельную структуру: отчуждаемый лоад-генератор, бэкенд для статистики и телеметрии, а также отдельный автоматизационный фреймворк. Окинув это взглядом и зная, что с YAC’10, где baabaka рассказывал про Лунапарк, тестеры всего Рунета при каждом удобном случае троллят нас открытием Лунапарка наружу, мы решили выложить часть Лунапарка в opensource. Летом 2012 года на одном из Яндекс.Субботников в Москве мы представили лоад-генератор сообществу тестировщиков. Сейчас Яндекс.Танк с легкими графиками, со встроенной поддержкой jmeter и ab развивается только на внешнем гитхабе, мы отвечаем на вопросы пользователей в клубике и принимаем внешние пулреквесты от разработчиков.
Мы знаем, что сообщество нагрузочных тестировщиков в Рунете невелико, доступные знания очень скудны и поверхностны, но тем не менее, интерес к теме производительности только нарастает. Поэтому будем рады поделиться накопленным опытом и знаниями в этой области и обещаем периодически публиковать статьи на тему нагрузок, инструментария и методов тестирования.
Тестирование в Яндексе: строим свой Лунапарк
Иной раз и секундного взгляда на график времен отклика хватает, чтобы сказать: сервис не полетит. Еще пара секунд — и причина найдена: ядра процессора загружены неравномерно, слишком мало потоков запущено на сервере. Как создать удобную систему сбора и хранения результатов нагрузочных тестов? О том, какой опыт об этом мы накопили в Яндексе, сегодня мой рассказ.
Кстати, я буду рассказывать о Яндекс.Танке и Graphite на Тестовой Среде, регистрация на которую будет открыта ещё до 18:00 18 ноября. Там можно будет задать свои вопросы вживую.
Если вы читали статью doctornkz о том, как организовано нагрузочное тестирование в Яндексе, то знаете, что результаты стрельб у нас лежат в хранилище, которое умеет их показывать через веб-интерфейс. Называется оно Лунапарк. Это очень удобно — провести тест и отправить ссылку на него всем заинтересованным людям (да и самому увидеть все на одной страничке). Сервис представляет собой веб-приложение, которое заточено на внутренние процессы (там и геймификация, и провязка с другими внутренними ресурсами), выкладывать которое в открытый доступ мы не планируем. Поэтому я решил рассказать, как построить подобную систему, используя только open-source продукты.
Архитектура системы
Система автоматизации — это модуль, который управляет запуском тестов, позволяет их параметризовывать, выполнять дополнительные действия (скачать лог продакшн-сервера или поднять тестовую среду). Все это можно осуществить с помощью таких инструментов, как Jenkins, Maven, Rake. Об этом сегодня рассказывать не буду, это тема для отдельного большого поста.
Генератор нагрузки — это рабочая лошадка, модуль, который создает нагрузку на мишень (тестовый стенд). Рассказ будет о Яндекс.Танке — это модульная и расширяемая стрелялка, позволяющая использовать внутри разные генераторы, в частности, знакомый многим JMeter. Отмечу, что Танк — это open-source проект, опубликованный Яндексом в 2012 году. Он не для новичков, нужно быть на «привет, как дела?» с линуксом, а еще лучше уметь писать простые скрипты.
И наконец, хранилище результатов. Танк стреляет в сервис и замеряет времена отклика и другие параметры. Получаются временные ряды, которые необходимо где-то хранить, а потом отображать и анализировать. Мы будем использовать для этого Graphite.
Graphite — это высокопроизводительное и масштабируемое хранилище временных рядов, написанное на Python. Open-source. В него очень просто загружать данные (а еще для этого существует много разных способов на любой вкус) и потом их удобно крутить через Web-API (и для этого тоже есть куча фронтэндов). Подробно о том, как Graphite используется в Яндексе, о его архитектуре и производительности можно послушать тут.
Установка Яндекс.Танка
Если у вас Ubuntu — вы везунчик. Потому что вам всего-то нужно подключить репозиторий Танка и установить его также, как все другие пакеты — зависимости вытянутся сами (здесь и далее могут потребоваться права root — обеспечьте их):
Собирать сам Танк не нужно — он на Python, однако нужно будет скачать и установить зависимости. Среди них есть Phantom — это высокопроизводительный веб-сервер, который Танк использует в качестве срелялки, тоже родом из Яндекса. Рассказ о нем можно послушать тут.
Необходимые python-библиотеки устанавливаются так:
Кроме этого вам придется собрать из исходников Phantom. Не буду тут объяснять, как это сделать, кому нужно — пишите, расскажу.
Пришло время пострелять
Чтобы пострелять танком, нужно написать для него конфигурационный файл (я сегодня немного КО). Я не буду вдаваться в тонкости, которых много, приведу простейший пример:
После создания файла — просто запускаем танк командой yandex-tank. По умолчанию он ищет конфиг с именем load.ini в текущей директории. Оно пошуршит-пошуршит, постреляет, на выходе будет текстовый файл phout*.log с данными, который обычно советуют запихнуть в gnuplot. Но мы ведь не такие, правда?
Ставим Graphite
К сожалению, официального deb-пакета для Graphite на данный момент нет, поэтому ставить будем из репозитория Python (pypi):
По умолчанию Graphite хранит данные с разрешением в 1 минуту. Нам этого, конечно, мало, в нагрузочных тестах важна каждая секунда. Настраиваем политики хранения данных:
Что за древние письмена? Я попросил Graphite, чтобы все метрики, подпадающие под regexp, указанный в параметре pattern, он хранил в соответствии с политикой, указанной в параметре retentions:
Тут все просто: секундная точность — семь дней, потом пятисекундная — в течение года.
And one more thing. Нужно обязательно настроить временную зону на вашу локальную, иначе, указав локальное время, графиков вы не увидете — попросту промахнетесь мимо ваших данных. Временная зона указывается в файле local_settings.py, например, так (по умолчанию файла нет):
Теперь создадим таблички в django:
Чтобы запустить Graphite, нужно стартовать хранилище carbon и веб-фронтенд:
Carbon по умолчанию ждет данных на 2003-м порту. Попробуем записать что-то в Graphite. Это очень просто, например:
Тут мы просто отправляем значение 1 с текущим таймстемпом в метрику «my.favourite.metric». А теперь зальем в Graphite содержимое /proc/vmstat (это уже юзабельно):
И конечно же, для заливки данных о системных ресурсах уже придумали много инструментов. Взгляните, например, на проекты Diamondи CollectD.
Посмотреть на залитые данные можно через веб-интерфейс, который по умолчанию слушает на порту 8080. Поиграйтесь с ним немного, а потом продолжим.
Подключаем Танк к Графиту
Ну что же! Пришло время подружить наших новых знакомых. Это тоже просто. Добавляем к конфигурационному файлу Танка вот такую секцию:
Квантили и среднее время ответа
По графику квантилей можно видеть распределение времен ответа каждую секунду.
Число запросов в секунду с разбивкой по маркерам
По этому графику можно отследить, сколько запросов приходилось на каждый маркер. Перед стрельбой патроны можно промаркировать, чтобы отделить, например, легкие от тяжелых.
Средние времена с разбивкой по маркерам
Как сервер реагирует на разные типы запросов — ответ тут.
Коды ответов
Если возникнут ошибки — вы увидите их на этом графике.
Кумулятивные квантили
В отличие от первого графика, тут квантили «копятся» с начала теста. Можно увидеть, когда они перестали меняться — это значит, вы настреляли достаточно для того, чтобы представлять, как в целом распределяются ответы.
Шаблон отчета
Все помнят, что в предыдущей секции мы обсуждали, как залить в Graphite данные о системных ресурсах? Как же увидеть и эти метрики тоже? Для генерации HTML-ки с картинками, Танк использует шаблон, который можно указать в опциях:
Шаблон — это просто HTML-ка с переменными, которые Танк подменяет. Например:
Одна ссылка на график в Graphite выглядит так:
В фигурных скобках мы видим подменяемые поля, название которых говорит само за себя. Вместо
Что в итоге?
Итак, мы получили стрелялку, которая заливает данные в Graphite и генерит HTML-ку со ссылками на эти данные. Как теперь запускать стрельбы автоматически? По cron? Можно и так. Но удобнее использовать Jenkins. Об этом как-нибудь в следующий раз. Stay tuned!
Кстати, если вы дочитали этот текст до конца, значит, тема вам интересна. Приходите обсудить её на Тестовую среду. На ней мои коллеги ко всему прочему расскажут про геймификацию и автоматизацию в нагрузочном тестировании. Приходите послушать и пообщаться!