Нагрузочное тестирование

Настраиваем нагрузочное тестирование с Artillery.io

30.05.2021 02:08:09 |

Автор: admin

Не так давно я начала писать тесты для нагрузочного тестирования с помощью инструмента artillery. Раньше писала тесты для K6, поэтому расскажу о преимуществах artillery по сравнению с К6, а также напишу пошаговый сценарий для настройки проекта с нуля.

Шаг 1. Установка

npm install g artillery@latest

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

npm i artillery-plugin-expect

Шаг 2. Создаем config

Target url, environment

Файл конфигурации нагрузочного тестирования это все, что нам нужно сделать для запуска тестов:

config:  target: "https://yourapp.com/api"

Если вам нужно использовать разные environment в ваших тестах, они прописываются сразу после target url:

config:  target: "https://bestapp.com/api"  environments:    dev:      target: "https://bestapp.dev.com/api"    qa:      target: "https://bestapp.qa.com/api"

Фазы тестирования

Инструмент artillery позволяет использовать несколько вариантов последовательных нагрузок на ваше приложение. Фаза тестирования состоит из: duration время одной фазы; arrivalRate количество пользователей, добавляемых каждую секунду; ramptTo до какого количества пользователей в секунду будет нарастать нагрузка; name - имя для обозначения ваших фаз.

phases:    - duration: 30      arrivalRate: 1      rampTo: 20      name: test1

Если у вас только один target url, то фазы нагрузочного тестирования размещаются сразу после него, если несколько environment, то добавляйте фазы в каждую переменную окружения.

Плагины

Добавляем плагин для ожидаемого результата:

plugins:    expect: {}

Авторизация

Инструмент поддерживает базовую авторизацию с помощью username и password:

- get:    url: "/auth"    auth:      user: username      pass: password

Также можно вставить свой авторизационный header:

- post:    url: "/auth"    headers:      Authorization: Basic secretKey

Шаг 3. Первый тест

Все тесты пишутся в разделе scenarios. Каждый сценарий имеет название, метод (GET, POST, PUT, DELETE и др.), url для каждого endpoint, body в формате json, а также необходимые проверки.

Пример простого теста:

scenarios:    - name: "My first test"       flow:         - post:            url: "/endpoint1"            json:              id: value        expect:           - statusCode: 200          - contentType: json           - equals:              - respMessage: "OK"

В equals добавляются все проверки, основанные на ответе вашего бэкэнда.

Шаг 4. Запуск тестов

Запуск нагрузочных тестов очень простой:

artillery run yourConfig.yml

Эту строку можно добавить в раздел scripts в package.json для быстрого запуска тестов.

-e <env> - запускает тесты для различных environment,
--quiet убирает все полученные результаты из консоли,
-o result.json добавляет результаты тестирования в файл отчета.

Создание html отчета

Отчет создается буквально в одну строку:

artillery report result.json

Сравнение с K6

Главное преимущество artillery это очень легкая настройка первого запуска тестов. Не надо переписывать тесты в формате, определяемом для K6, не надо писать bat-файл для того, чтобы запускать несколько тестов и сохранять результаты в отдельную папку. Достаточно сконфигурировать один файл.

Artillery работает с node.js, поэтому скрипт для запуска можно вставить в package.json.

Можно импортировать переменные из cvs-файла, брать переменные из полученного результата.

Отчет с графиками и диаграммами добавляется в одну команду и входит в бесплатную версию artillery.

Подробнее..

Категории: Javascript , Api , Тестирование веб-сервисов , Нагрузочное тестирование , Artillery

Оценка достоверности отчетов об ошибках с помощью анализа временных рядов

01.02.2021 16:08:09 |

Автор: admin

Source: W. Playfair.

Привет, Хабр! Меня зовут Илья Селицер. В DINS мы участвуем в разработке продукта для UCaaS-провайдера RingCentral, который объединяет много функций от звонков и факса до корпоративного мессенджера и видеоконференций. Я, среди прочего, отвечаю за качество этого сервиса. В повседневной практике мне постоянно приходится анализировать взаимодействие различных сетевых элементов, которые участвуют в предоставлении той или иной услуги абонентам.

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

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

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

Для оценки качества услуги UCaaS-провайдеры могут использовать отчеты об ошибках, формируемые на основе сообщений об ошибках от различных сетевых элементов. Эти отчеты представляются в удобном для анализа виде: таблицы, графики и т.д. Но далеко не всегда по виду таблицы или графика можно сказать, насколько достоверно они отражают процессы, происходящие в сложной многокомпонентной системе. В этом случае для анализа можно использовать различные статистические методы, в частности, анализ временных рядов и тестирование гипотез.

Рассмотрим пример: UCaaS-провайдер предоставляет некоторую услугу S (например, прием факсовых, мультимедийных и прочих сообщений, голосовую почту, запись аудио- или видеозвонка) бизнес-абонентам в нескольких регионах R_i. Процесс предоставления S имеет следующие особенности:

Результат успешного предоставления услуги (SS) файл F_k некоторого объёма, который сохраняется в течение определённого периода времени в сетевом хранилище. Объём F_k пропорционален размеру сообщения.
Информация о количестве фактов успешного предоставления S для каждого R_i достоверна.
Сетевые элементы NE_ij, непосредственно участвующие в предоставлении S, генерируют отчёты об ошибках ER_j, т.е. о фактах неуспешного предоставления S (SE). Эта информация может быть недостоверной в силу разных причин, таких как ошибки в алгоритме подсчета ошибок, проблемы на уровне ОС, аппаратные проблемы и.т.д.
Отчёт об ошибках по региону SER_i формируется для каждого R_i путем суммирования ER_j по отчетам от каждого NE_ij.

Нам нужно оценить, насколько достоверно отчёты SER_i отражают реальное количество ошибок, а также спланировать дальнейшие действия в зависимости от результатов оценки. До начала анализа определимся с действиями:

Результаты оценки достоверно. Не делаем ничего, т.е. не тратим ресурсы на дальнейший анализ. Оцениваем качество услуги на основе SER_i и количества жалоб на качество услуги со стороны абонентов.
Результаты оценки недостоверно. Изменяем механизм формирования ER_j. Это весьма ресурсоемкая задача, так как потребуется не только дополнительный анализ сценариев взаимодействия, но, возможно, доработка сетевых элементов и даже изменение архитектуры предоставления S.

На основе данных о технологии оказания той или иной услуги, а также результатов наблюдения за системой, можно сделать следующие предположения:

Потребление S растёт со временем. Это обусловлено, например, ростом абонентской базы и/или растущим спросом на S.
Количество запросов на предоставление S изменяется с некоторой периодичностью, характерной для бизнес-пользователей, например, рабочие дни-выходные.
Количество SE растет с ростом потребления, т.е. количества фактов успешного оказания услуги, например, из-за перегрузки сетевых элементов.
Количество SE растет с ростом среднего объёма F_k. Например, количество ошибок при приёме факсового сообщения вырастет с ростом размера принимаемых факсовых сообщений (и, соответственно, объёма файлов F_k): приём 10-страничного факса потребует больше времени, чем 1-страничного, вероятность возникновения ошибки при приёме увеличивается с ростом времени приёма при прочих равных условиях. Следовательно, число ошибок при приёме большого количества 10-страничных факсов будет больше, чем при приёме такого же количества 1-страничных.

Исходя из утверждений 1-4, а также учитывая, что зависимости SS и SE от времени суть временные ряды (time series, TS), используем следующие возможные результаты анализа TS SE (TSE), по которым будем определять степень достоверности информации, предоставляемой отчётами об ошибках:

TSE стационарен, т.е. не имеет сезонности и тренда.
TSE нестационарен, т.е. демонстрирует сезонность (seasonality) и тренд (trend) это и будет принято в качестве критерия достоверности данных, предоставляемый TSE.

Нестационарный TS может и не иметь тренда, один из примеров случайное блуждание (random walk, RW), хотя этот факт применительно к RW, в некоторых случаях, подлежит обсуждению.
В качестве инструментов анализа будем использовать различные методы тестирования стационарности TS, а также оценку автокорреляции TS (ACF). Используем TSS и TSE для одного из регионов, полученные на реальной сети UCaaS-провайдера. Для анализа используем Python и соответствующие статистические и графические библиотеки. Код доступен здесь, для просмотра кода и графиков можно использовать nbviewer.

TSS

Сначала проанализируем TSS. Построим графики TSS и декомпозиции TSS, коррелограмму рис. 1-3. Для декомпозиции использованы следующие значения параметров:

model = multiplicative. Мы рассматриваем TSS как произведение трёх компонент: тренда, сезонных колебаний и случайной величины (остаток, residuals) [1]. На мультипликативную модель указывает, например, возрастающий со временем размах сезонных колебаний.
period = 7 (period = None даст тот же результат).

Рис. 1. TSS

Рис. 2. Декомпозиция TSS

Рис. 3. Коррелограмма TSS

Анализ графиков на рис. 1-3 приводит к следующим выводам:

Сезонность чётко различима и равна 7 дням (рис.1).
Присутствует положительный тренд (рис. 2). Это случай детерминированного тренда: несмотря на скачкообразные изменения значений тренда, его наклон (slope coefficient) возвращается к исходному значению на более длительном отрезке времени.
Величина автокорреляции уменьшается с ростом лага. Это обусловлено трендом, тогда как форма, напоминающая затухающую синусоиду, это следствие сезонности. В нашем случае корреляция между значениями TSS в момент t максимальна в момент t n*7 дней, n = 1 5. Закрашенная область на рис. 3 это доверительный интервал (confidence interval, CI) для ACF. Значения ACF, попадающие за пределы этой области, статистически значимы.

Наличие сезонности и тренда говорит о нестационарности TSS [1]. Проверим TSS на стационарность с помощью ADF-теста (Augmented Dickey-Fuller). ADF-тест в качестве нулевой гипотезы (H₀) постулирует наличие единичного корня [2, 3], что указывает на нестационарность TS. При этом отсутствие единичного корня не говорит о стационарности TS. Получаем следующие результаты:

p-value > 0.05, результат не является статистически значимым, H₀ не может быть отвергнута.
Как и предполагалось до начала анализа, TSS нестационарен, что подтверждается собственно графиком процесса, результатами декомпозиции, коррелограммой, ADF-тестом.

Объём Fk

Как указано выше, размер сообщений пропорционален объёму F_k. Оценим, как меняются значения Fk со временем. Гистограмма с линейным масштабом F_k см. рис. 4, с логарифмическим масштабом см. рис. 5, коробчатая диаграмма (box plot) см. рис. 6.

Рис. 4. Гистограмма Fk, линейный масштаб

Рис. 5. Гистограмма Fk, логарифмический масштаб

Некоторые выводы по рис. 4, 5:

Распределение несимметрично, присутствует правый хвост (right-skewed).
Среди значений объёма F_k присутствуют экстремальные значения/выбросы (outliers).
Среди экстремальных значений присутствуют нулевые значения, являющиеся результатом округления F_k в меньшую сторону.

Рис. 6. Коробчатая диаграмма Fk

Коробчатая диаграмма на риc. 6 показывает, что:

Количество экстремальных значений F_k > 55 заметно уменьшилось;
Медиана несколько выросла, несмотря на колебания от месяца к месяцу;
Характер распределения F_k примерно одинаков от месяца к месяцу. Средние, медианные и максимальные значения F_k по месяцам:

Несмотря на некоторые колебания, медиана F_k растёт со временем, количество экстремальных значений изменяется в сравнительно небольших пределах. Более детальное изучение распределения F_k также необходимо для понимания особенностей использования S потребителями и является предметом отдельного исследования.

Информация, представленная в виде графиков на рис. 1-6, в значительной степени совпадает с предположениями 1-4.

TSE

Построим TSE и попытаемся обнаружить и оценить особенности этого графика.

Рис. 7. TSE

График на рис. 7 не показывает явно выраженную сезонность, также присутствуют нулевые значения SE.

Проведём декомпозицию TSE см. рис. 8. Параметр model=additive т.к. в TSE присутствуют нулевые значения, period = None.

Рис. 8. Декомпозиция TSE

Декомпозиция TSE указывает на сезонность с периодом 7 дней, а также на отсутствие выраженного тренда.

Рис. 9. Коррелограмма TSE

Коррелограмма на рис. 9 также не показывает сезонность, как в случае TSS: всего два значения статистически значимы, остальные значения статистически незначимы. В то время как декомпозиция TSE указывает на наличие сезонности TSE с периодом 7 дней, коррелограмма TSE не показывает заметной автокорреляции с лагом, кратным 7 (рис. 9). Тот факт, что используемый для данного случая алгоритм декомпозиции обнаружил сезонную компоненту, не означает, что сезонность присутствует или существенно определяет свойства TSE: даже для RW этот алгоритм декомпозиции обнаруживает сезонную компоненту. В этом случае необходимо использовать другие доступные методы оценки стационарности TSE.

ADF-тест даёт следующие результаты:

Значение p-value << 0.05, результат статистически значим, принимаем альтернативную гипотезу (H₁): TSE стационарен. Для более надежной проверки, в дополнение к ADF-тесту используем KPSS-тест (Kwiatkowski-Phillips-Schmidt-Shin). В отличие от ADF-теста, KPSS-тест постулирует в качестве H₀ стационарность процесса, а в качестве H₁ наличие единичного корня. ADF- и KPSS-тестам свойственны некоторые недостатки, например, высокий уровень ошибок первого рода (ошибочное отвержение H₀), однако совместное применение ADF- и KPSS-тестов позволит уменьшить влияние этих недостатков на результаты анализа TSE [3].
KPSS-тест даёт следующие результаты:

Здесь p-value > 0.05, т.е. не является статистически значимым, принимаем H₀: TSE стационарен.

Приходим к следующим выводам:

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

Заключение

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

Вопросы или комментарии читателей, возникшие по прочтении данной статьи, приветствуются.

Литература

Подробнее..

Категории: Python , Блог компании dins , Нагрузочное тестирование , Timeseries , Eda

Программные IP-АТС, E1, DSS-1 и нагрузочное тестирование

15.07.2020 22:07:35 |

Автор: admin

Всем доброго вечера! Сегодня я решил написать про тестирование протокола DSS-1 в IP-АТС, начнем как всегда с теории, рассмотрим преобразования сообщений из SIP в DSS-1, поговорим про анализаторы протоколов и закончим нагрузочным тестированием.

Введение
Как говориться без теории никуда, хоть информации о потоке E1 и протоколе DSS-1 предостаточно, опишу основные моменты, которые важны для понимания дальнейшего материала.
Протокол DSS-1 имеет три уровня.
Первый уровень физический, отвечает за непосредственно установление физического соединений и формирование каналов PRI и BRI. Basic Rate Interface (BRI) содержит 2 B канала 64 кбит/с и один D-канал 16 кбит/с, Primary Rate Interface (PRI) содержит 30 B каналов 64 кбит/с и 2 D-канала 64 кбит/с. B-каналы передают голос, данные, в то время как D-каналы являются сигнальными. Один из каналов сигнализации служит для синхронизации оконечного оборудования, другой для передачи данных об устанавливаемых соединениях.
Второй уровень канальный, на данном уровне работает протокол Link Access Protocol D Channel (LAPD) спецификация Q.921. Протокол LAPD отвечает за формирование логических каналов. Соответственно после установлении физического соединения должно установиться логическое: NETWORK посылает сообщение SABME (Set Asynchronous Balanced Mode Extended, установить расширенный асинхронный режим), CPE отвечает сообщением UA (Unnumbered Acknowledge, ненумерованное подтверждение) для синхронизации. После этого между устройствами NETWORK и CPE должен постоянно поддерживаться обмен RR (Receiver Ready, приемник готов) и устанавливаются логические каналы D и B.
Третий уровень сетевой, на данном уровне у нас ходит сигнализация протокол Q.931, который передается в канале D и данные протокола Х.25, передаются в канале B.

SIP в DSS-1
Теперь, когда мы разобрались, как работает протокол DSS-1, рассмотрим, как происходит преобразование протокола SIP в EDSS-1 и обратно. На рисунке 1 показано стандартное установление соединения. Как мы видим из рисунка сообщения протокола SIP и DSS-1 похожи.

Рисунок 1 Преобразование SIP в DSS-1

Анализ потока E1
Теперь поговорим, как нам анализировать поток E1. Про физику потока его форму импульса мы говорить не будем, нас интересует исключительно логика. На моей практике было и такое, что две АТС отлично работают по E1 и только подключив анализатор протоколов мы видели ошибки.
Анализатор нам нужен для отображения сообщений протоколов второго и третьего уровня, с помощью него мы увидим потерю сигнала, срыв синхронизации и многое другое. Естественно с одной стороны мы ставим нашу АТС, с другой желательно устанавливать серийную АТС, ловить ошибки на ошибки нам не надо.
Для анализа протоколов нам может пригодится Linkbit AnyTest AT1000 или Asterisk + T1/E1 (PRI) Digital Card.

Linkbit AnyTest AT1000
Немного расскажу о Linkbit, по сути это аппаратно-программный комплекс, являющийся анализатором протоколов цифровой телефонии. Представляет собой приставку с интерфейсами, которая подключается по usb к компьютеру с установленным программным обеспечением. Поддерживает большое количество протоколов и кодеков, в том числе и интересующих нас DSS-1 и SIP.
На рисунке 2 показан графический интерфейс. В графическом интерфейсе отображается окно с расшифровкой сообщений DSS-1 и LAPD, при необходимости можно отключить отображение сообщений не интересующего протокола. Ниже отображается поток E1 c тайм-слотами, как мы видим на рисунке 2 у нас заняты 10 тайм-слотов (отображены зеленым), 3 освободились (отображаются черным), стоит отметить, что при нажатии на занятый тайм-слот мы можем прослушать разговор.

Рисунок 2 Анализатор протоколов Linkbit AnyTest AT1000

Asterisk + T1/E1 (PRI) Digital Card
Теперь поговорим о Asterisk, для работы нам понадобится T1/E1 (PRI) Digital Cards, которая устанавливается в слот PCI Express, соответственно немного придётся повозиться, что бы Asterisk увидел ее.
Заходим в отладку Asterisk и вводим команду pri debug span 1 (указали номер своего канала) и при входящем/исходящем мы будем видеть сообщение протокола DSS-1. Соответственно, что бы нам увидеть статус каналов мы можем воспользоваться командой pri show span 1. Если хочется увидеть сообщение LAPD, то следует воспользоваться командой pri intense debug span 1.

Рисунок 3 Отладка Asterisk: сообщения DSSS-1

Рисунок 4 Отладка Asterisk: отображение тайм-слотов

Нагрузочное тестирование
Вариант 1
Для проверки программной IP-АТС нам понадобится серийная IP-АТС, в разрыв потока E1 ставится Linkbit AnyTest AT1000, дальше используются генераторы трафика StarTrinity SIP Tester или Sipp. Сообщение протоколов анализируем с помощью Linkbit AnyTest AT1000.

Вариант 2
Для проверки программной IP-АТС нам понадобится серийная IP-АТС, в разрыв потока E1 ставится Linkbit AnyTest AT1000, дальше используются генераторы трафика StarTrinity SIP Tester или Sipp, которые осуществляют вызовы на Asterisk (Asterisk подымает трубку и заворачивает RTP). Сообщение протоколов анализируем с помощью Linkbit AnyTest AT1000.

Рисунок 6 Варианты тестирования

Вариант 3
Для проверки программной IP-АТС нам понадобится Asterisk + T1/E1 (PRI) Digital Card в разрыв потока E1 ставится анализатор потока E1. Дальше используются генераторы трафика StarTrinity SIP Tester или Sipp, которые осуществляют вызовы на Asterisk (Asterisk подымает трубку и заворачивает RTP). Сообщение протоколов анализируем с помощью Linkbit AnyTest AT1000.

Вариант 4
Для проверки программной IP-АТС нам понадобится Asterisk + T1/E1 (PRI) Digital Card. Дальше используются генераторы трафика StarTrinity SIP Tester или Sipp, которые осуществляют вызовы на Asterisk (Asterisk подымает трубку и заворачивает RTP). Сообщение протоколов анализируем с помощью программных возможностей Asterisk. Сообщение протоколов анализируем с помощью Linkbit AnyTest AT1000.

Рисунок 7 Варианты тестирования

У меня было несколько видов проверок первая я занимал 30 каналов и с определенным интервалом устанавливал вызовы, что бы отбившийся канал занимался новым и так по кругу, проще всего это сделать с помощью StarTrinity SIP Tester. Вторая направлял вал вызовов через поток и смотрел как будет реагировать программное обеспечение.

Подведение итогов
Подведем итоги, мы с вами разобрались как работает протокол EDSS-1, нашли способы проанализировать сообщения протокола и произвели нагрузочное тестирование программного обеспечения. Конечно, в данном посте нет описания сообщений и всех тонкостей работы протокола, но для этого есть ссылки с рекомендуемыми спецификациями и литературой.

LOADING.

Ссылки
1.ITU-T Recommendation Q.921 (I.451)
2.ITU-T Recommendation Q.931 (I.451)
3.Гольдштейн Б.С. Протоколы сети доступа. Том 2.

Подробнее..

Категории: Asterisk , Sip , Тестирование it-систем , Нагрузочное тестирование , Dss-1 , Телефония

Генератор трафика Cisco TRex запускаем нагрузочное тестирование сетевых устройств

13.07.2020 10:06:40 |

Автор: admin

При разработке очередного роутера мы тестировали производительность сети с помощью полезной open-source-штуки генератора трафика Cisco TRex. Что это за инструмент? Как им пользоваться? И чем он может пригодится инженерам-разработчикам? Под катом ответы на эти вопросы.

1. Что такое Cisco TRex

Это программный генератор трафика с открытым исходным кодом, работает на стандартных процессорах Intel на базе DPDK, поддерживает режимы с контролем состояния потока и без (stateful / stateless modes). Сравнительно простой и полностью масштабируемый.

Англоязычная документация для этого инструмента доступна на сайте https://trex-tgn.cisco.com/trex/doc

Trex позволяет генерировать разные типы трафика и анализировать данные при их получении. Поддерживается работа на уровне MAC и IP. Можно задавать размер пакетов и их количество, контролировать скорость передачи данных.

Работа с генератором организована в среде Linux.

Одно из важных отличий генератора Trex использование технологии DPDK, которая позволяет обойти узкие места в производительности сетевого стека Linux. DPDK или Data Plane Development Kit это целый набор библиотек и драйверов для быстрой обработки пакетов, который позволяет исключить сетевой стек Linux из процесса обработки пакетов и взаимодействовать с сетевым устройством напрямую.

DPDK превращает процессор общего назначения в сервер пересылки пакетов. Благодаря этой трансформации отпадает необходимость в дорогостоящих коммутаторах и маршрутизаторах. Однако DPDK накладывает ограничения на использование конкретных сетевых адаптеров, список поддерживаемого железа указан на http://core.dpdk.org/supported тут самая популярная платформа от Intel, т.е. обеспечена поддердка железа, которое работает с linux-драйверами e1000, ixgbe, i40e, ice, fm10k, ipn3ke, ifc, igc.

Также важно понимать, что для работы TRex-сервера на скоростях 10 Гбит/с необходим многоядерный процессор от 4 ядер и выше, желательно CPU семейства Intel c поддержкой одновременной многопоточности (hyper-threading).

2. Как получить и попробовать TRex

1) Загружаем архив с сервера trex-tgn.cisco.com:
https://trex-tgn.cisco.com/trex/release/

Распаковываем архив в домашней директории пользователя /home/user, где user имя пользователя.

[bash]>wget --no-cache https://trex-tgn.cisco.com/trex/release/latest[bash]>tar -xzvf latest

2) Настраиваем интерфейсы отправки и приема данных

Выполним настройку с помощью утилиты dpdk_setup_ports.py, которая идет в архиве с TRex. Конфигурировать сетевые интерфейсы, которые использует TRex, можно на уровне MAC или IP. Для старта необходимо запустить данную утилиту с ключом интерактивной настройки sudo ./dpdk_setup_ports.py i.

Первым шагом откажемся от конфигурации на MAC-уровне (Do you want to use MAC based config? (y/N) n).

Вторым шагом необходимо выбрать пару сетевых интерфейсов, с которыми будем работать, в нашем случае сетевая карта Intel X710 работает с 4 сетевыми интерфейсами, будем использовать 1-е и 4-е гнездо сетевой карты.

Третьим шагом система предложит автоматически создать замкнутую конфигурацию когда данные уходят с порта 1 и приходят в порт 2 (и обратно), все на одном ПК. Нам пришлось отказаться от данной схемы и настроить схему маршрутизации на 2 ПК.

Четвертым и пятым шагом даем согласие на сохранение конфигурации в файл /etc/trex_cfg.yaml.

Для примера рассмотрим конфигурацию на IP-уровне для следующей схемы подключения:

Файл конфигурации находится тут: /etc/trex_cfg.yaml. Простой конфигурационный файл показан ниже для сетевой карты с 2 портами и CPU, поддерживающем 8 потоков:

### Config file generated by dpdk_setup_ports.py ###- version: 2  interfaces: ['01:00.0', '01:00.3']  port_info:      - ip: 192.168.253.106        default_gw: 192.168.253.107      - ip: 192.168.254.106        default_gw: 192.168.254.107   platform:      master_thread_id: 0      latency_thread_id: 1      dual_if:    - socket: 0      threads: [2,3,4,5,6,7]

В конфигурации:

'01:00.0', '01:00.3' наименование Eth-интерфейсов в используемой системе Linux.
ip: 192.168.253.106 адрес порта ПК Server TRex, с которого генерируется трафик.
default_gw: 192.168.253.107 адрес 1 порта ПК DUT (Device under test).
ip: 192.168.254.106 адрес порта ПК Server TRex, с которого возвращается трафик после прохождения через правила QOS.
default_gw: 192.168.253.107 адрес 2 порта ПК DUT.

Внимание! Система TRex запрещает использование той же подсети при генерации потоков, что используются системой, для этого при генерации пакетов используются подсети 16.0.0.0 и 48.0.0.0.

3) Настраиваем интерфейсы на удаленной машине

Необходимо настроить пересылку (forwarding) и маршруты, чтобы система (DUT), через которую будем пропускать трафик, знала, откуда принимать и куда отправлять пакеты.

Настраиваем на ПК DUT правила маршрутизации потоков:

sudo echo 1 > /proc/sys/net/ipv4/ip_forwardsudo route add -net 16.0.0.0 netmask 255.0.0.0 gw 192.168.253.106sudo route add -net 48.0.0.0 netmask 255.0.0.0 gw 192.168.254.106

4) Запускаем TRex-сервер в режиме astf:

cd v2.XXsudo ./t-rex-64 -i --astf

При успешном запуске TRex-сервера, увидим информацию о Ethernet-портах, занятых под тестирование:

The ports are bound/configured.port : 0 ------------link         :  link : Link Up - speed 10000 Mbps - full-duplexpromiscuous  : 0 port : 1 ------------link         :  link : Link Up - speed 10000 Mbps - full-duplexpromiscuous  : 0 number of ports         : 2 max cores for 2 ports   : 1 tx queues per port      : 3

5) Запускаем консоль TRex

С помощью консоли в отдельном окне запускаем генерацию потока из готовых примеров (папка с примерами astf есть в архиве к TRex):

cd v2.XX./trex-consolestart -f astf/http_simple.py -m 1 start (options):-a (all ports)-port 1 2 3 (ports 1 2 3)-d duration (-d 100 -d 10m -d 1h)-m stream strength (-m 1 -m 1gb -m 40%)-f load from disk the streams file

При успешном запуске увидим статистику по прохождению трафика в консоли TRex-сервера:

Global stats enabledCpu Utilization : 0.3  %  0.6 Gb/core Platform_factor : 1.0  Total-Tx        :     759.81 Kbps  Total-Rx        :     759.81 Kbps  Total-PPS       :      82.81  pps  Total-CPS       :       2.69  cps   Expected-PPS    :       0.00  pps  Expected-CPS    :       0.00  cps  Expected-L7-BPS :       0.00  bps   Active-flows    :        2  Clients :        0   Socket-util : 0.0000 %    Open-flows      :      641

3. Автоматизация разработки и тестирования с помощью TRex

В процессе разработки сетевого роутера мы написали много тестов для TRex, соответственно встал вопрос по их прогону в автоматическом режиме с помощью python. Как мы это организовали:

Запустили TRex-сервер в режиме stl:

cd v2.XXsudo ./t-rex-64 -i --stl

Задали переменную окружения для python, так как TRex работает в связке с python.
export PYTHONPATH=/home/!!!user!!!/v2.XX/automation/trex_control_plane/interactive,
где, !!!user!!! имя пользователя и домашняя директория, v2.XX версия ПО TRex, загруженная и распакованная в данную папку.

Запустили генератор трафика с помощью python, листинг примера конфигурации приведен ниже.

python example_test_2bidirectstream.py

Ожидаемый результат:

Transmit: 10000.24576MByte/s Receive: 10000.272384MByte/sStream 1 TX: 4487179200 Bit/s RX: 4487179200 Bit/sStream 2 TX: 2492873600 Bit/s RX: 2492873600 Bit/sStream 3 TX: 1994294400 Bit/s RX: 1994294400 Bit/sStream 4 TX: 997147200 Bit/s RX: 997147200 Bit/s

Разберем данный пример:
c = STLClient(server = '127.0.0.1')

Создаем подключение к TRex-серверу, в данном случае подключение создается к той же машине, где и сервер.

base_pkt_dir_a, base_pkt_dir_b, base_pkt_dir_c, base_pkt_dir_d шаблоны пакетов, в которых указаны адреса источника и получателя, и порты источника и получателя. В данном примере создается 4 потока, 2 в одну сторону и 2 в обратную.
s1, s2, s3, s4 у класса STLStream запрашиваем параметры генерируемого потока, такие как ID потока и bitrate, в нашем случае ID1=4.5 Гбит/с, ID2=2.5 Гбит/с, ID3=2 Гбит/с, ID4=1 Гбит/с.

Листинг файла конфигурации потоков example_test_2bidirectstream.py

# get TRex APIsfrom trex_stl_lib.api import * c = STLClient(server = '127.0.0.1')c.connect() try:    # create a base packet with scapy    base_pkt_dir_a = Ether()/IP(src="16.0.0.1",dst="48.0.0.1")/UDP(dport=5001,sport=50001)    base_pkt_dir_b = Ether()/IP(src="48.0.0.1",dst="16.0.0.1")/UDP(dport=50001,sport=5001)     base_pkt_dir_c = Ether()/IP(src="16.0.0.2",dst="48.0.0.2")/UDP(dport=5002,sport=50002)    base_pkt_dir_d = Ether()/IP(src="48.0.0.2",dst="16.0.0.2")/UDP(dport=50002,sport=5002)     # pps : float    # Packets per second    #    # bps_L1 : float    # Bits per second L1 (with IPG)    #    # bps_L2 : float    # Bits per second L2 (Ethernet-FCS)    packet_size = 1400     def pad(base_pkt):        pad = (packet_size - len(base_pkt)) * 'x'        return pad     s1 = STLStream(packet=STLPktBuilder(base_pkt_dir_a/pad(base_pkt_dir_a)), mode=STLTXCont(bps_L2=4500000000), flow_stats=STLFlowStats(pg_id=1))    s2 = STLStream(packet=STLPktBuilder(base_pkt_dir_b/pad(base_pkt_dir_b)), mode=STLTXCont(bps_L2=2500000000), flow_stats=STLFlowStats(pg_id=2))    s3 = STLStream(packet=STLPktBuilder(base_pkt_dir_c/pad(base_pkt_dir_c)), mode=STLTXCont(bps_L2=2000000000), flow_stats=STLFlowStats(pg_id=3))    s4 = STLStream(packet=STLPktBuilder(base_pkt_dir_d/pad(base_pkt_dir_d)), mode=STLTXCont(bps_L2=1000000000), flow_stats=STLFlowStats(pg_id=4))     my_ports = [0, 1]     c.reset(ports = [my_ports[0], my_ports[1]])     # add the streams    c.add_streams(s1, ports = my_ports[0])    c.add_streams(s2, ports = my_ports[1])    c.add_streams(s3, ports = my_ports[0])    c.add_streams(s4, ports = my_ports[1])     # start traffic with limit of 10 seconds (otherwise it will continue forever)    # bi direction    testduration = 10    c.start(ports=[my_ports[0], my_ports[1]], duration=testduration)    # hold until traffic ends    c.wait_on_traffic()     # check out the stats    stats = c.get_stats()     # get global stats    totalstats = stats['global']    totaltx = round(totalstats.get('tx_bps'))    totalrx = round(totalstats.get('rx_bps'))    print('Transmit: {}MByte/s Receive: {}MByte/s'.format((totaltx / 1000000), (totalrx / 1000000)))    c.clear_stats(ports = [my_ports[0], my_ports[1]])     # get flow stats    totalstats = stats['flow_stats']    stream1 = totalstats[1]     stream2 = totalstats[2]    stream3 = totalstats[3]    stream4 = totalstats[4]    totaltx_1 = stream1.get('tx_pkts')    totalrx_1 = stream1.get('rx_pkts')    print('Stream 1 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_1['total'] / testduration * packet_size * 8),                                                               (totalrx_1['total'] / testduration * packet_size * 8)))    totaltx_2 = stream2.get('tx_pkts')    totalrx_2 = stream2.get('rx_pkts')    print('Stream 2 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_2['total'] / testduration * packet_size * 8),                                                               (totalrx_2['total'] / testduration * packet_size * 8)))    totaltx_3 = stream3.get('tx_pkts')    totalrx_3 = stream3.get('rx_pkts')    print('Stream 3 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_3['total'] / testduration * packet_size * 8),                                                               (totalrx_3['total'] / testduration * packet_size * 8)))    totaltx_4 = stream4.get('tx_pkts')    totalrx_4 = stream4.get('rx_pkts')    print('Stream 4 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_4['total'] / testduration * packet_size * 8),                                                               (totalrx_4['total'] / testduration * packet_size * 8)))except STLError as e:    print(e) finally:    c.disconnect()

Заключение

При подготовке этого руководства для Хабра мы запустили и проверили работу системы DUT с 4 потоками, собрали информацию по потокам и глобальную статистику.

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

Так чем же TRex компании Cisco лучше или хуже других аналогичных генераторов трафика? Например, популярной клиент-серверной программы iperf? В сценарии использования TRex мы видим описание настройки и работы с потоками. Оба средства тестирования и отладки хороши: iperf для быстрой проверки функциональности на ходу, а TRex отлично справляется с автоматизацией тестирования и разработки сложных сетевых устройств и систем, где важна возможность настройки многопоточных стримов, чтобы каждый поток конфигурировать под конкретную задачу и анализировать результаты на выходе.

TRex позволяет создавать шаблоны практически любого вида трафика и усиливать их для генерации крупномасштабных DDoS-атак, в том числе TCP-SYN, UDP и ICMP-потоков. Возможность генерации массивных потоков трафика позволяет моделировать атаки от различных клиентов на множество целевых серверов.

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

Подробнее..

Категории: Linux , Высокая производительность , Тестирование it-систем , Производство и разработка электроники , Intel , Сетевые технологии , Сетевое оборудование , Разработка под linux , Нагрузочное тестирование , Cisco , Разработка сетевой инфраструктуры , Trex , Promwad , Разработка электроники , Iperf , Dpdk

Из песочницы Анализ результатов нагрузочного тестирования

08.08.2020 00:06:58 |

Автор: admin

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

В настоящий момент наиболее популярными инструментами тестирования являются Gatling, MF LoadRunner, Apache JMeter. Все они обладают возможностями как генерации готовых отчетов по проведенному тестированию, так и отдельных графиков или сырых данных, на основе которых строится уже сам отчет.

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

Мы в Тинькофф активно используем инструмент Gatling, поэтому на его примере расскажем, как создать отчет вашей мечты и куда следует смотреть при его анализе. Также сразу хочу заметить, что почти все графики, описанные в статье, можно получать в режиме онлайн с помощью связки вашего инструмента с Grafana. Это наиболее удобный инструмент для создания отчетов на лету, с помощью сконфигурированного заранее дашборда. Более того, это позволяет более быстро создать почти любой график на основе отправленных вами данных. Уже сейчас есть готовые дашборды почти для всех инструментов нагрузочного тестирования. Графики для других инструментов MF LoadRunner и Apache JMeter тоже будут приведены, их анализ строится по аналогии с Gatling.

Основные метрики

Индикаторы

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

Пороги для перехода из группы в группу задаются заранее на основе экспертной оценки или SLA (нефункциональных требований). Например, может быть три группы:

отличная время отклика менее 50 секунд;
средняя более 50, но менее 100 секунд;
ужасная более 100 секунд.

В Gatling вы сами можете настроить пороги для перехода из группы в группу и их количество в файле gatling.conf. Графики такого типа лучше строить на основе методики. APDEX (Application Performance Index)
Также можно добавить индикатор с количеством/процентами ошибочных запросов.

Метод APDEX позволяет использовать индикаторы в регрессионном тестировании для сравнения релизов: так сразу видно, насколько хуже или лучше стал релиз в общем. К сожалению, этого графика нет из коробки в MF LoadRunner и Apache JMeter, но его легко создать с помощью дашборда Grafana.

Таблица с временем отклика

По умолчанию Gatling строит таблицу по перцентилям, среднему и максимальному времени отклика, а также по ошибкам. По ней отслеживается выход за пределы SLA (превышение нефункциональных требований). Обычно в SLA указывают перцентили 95, 99 и процент ошибок. Таким образом таблица позволяет получить быструю оценку результатов тестирования.

Если группировать запросы в виде транзакций, можно увидеть в таблице как оценку отдельных запросов, так и оценку всей группы и транзакции сразу.

HTML Gatling Report
MF LoadRunner также создает таблицу сам в блоке Analysis Summary Report и называется Transaction Summary
В Apache JMeter эти данные можно найти в Aggregate Report

График Virtual Users

Обычно измеряется в штуках и показывает, как пользователи заходят в приложение, тем самым иллюстрируя реальный профиль нагрузки. Стоит сразу оговориться, что для MF LoadRunner и Gatling эти графики показывают количество Virtual Users, а для Apache JMeter количество Thread.

График используют для контроля правильности подачи нагрузки. Необходимо, чтобы ваш расчетный сценарий соответствовал тому, что вы подали на систему в реальности. Например, если вы видите на графике большие отклонения от планируемого сценария в верхнюю сторону, значит, что-то пошло не так: ошибка в расчете, запущено больше, чем нужно, копий инструмента нагрузки и так далее. Возможно, дальнейшие графики уже нет смысла анализировать, так как вы подали на 100 пользователей больше, чем планировали, а система изначально проектировалась для работы лишь 10 пользователей.
Этот график разделяется на два вида:

Active Users отображает, сколько потоков сейчас активно в секунду. Когда потоки стартуют и останавливаются, особенно в открытой модели нагрузки, этот показатель будет колебаться на протяжении всего теста.
Total VUsers показывает, сколько потоков стартовали и останавливались с начала тестирования суммарно. Удобно для закрытой модели нагрузки, в которой потоки не умирают.

Вид графика также зависит от модели нагрузки:

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

HTML Gatling Report
В MF LoadRunner этот график называется Running Vusers
В Apache JMeter график называется Active Threads Over Time и не входит в стандартную поставку, но его можно бесплатно скачать на сайте JMeter-Plugins.org

График Response Time

Чаще всего измеряется в миллисекундах показывает время ответа на запросы к приложению. Время отклика не должно превышать SLA. Этот график является основным инструментом для поиска точек деградации при проведении нагрузочного тестирования.

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

Кроме графика времени ответа каждого запроса удобно показывать также линию с суммарным временем ответа (Total Response Time). Если наложить график подаваемой нагрузки (VU/RPS), можно отслеживать корреляцию с увеличением времени отклика от увеличения подаваемой нагрузки (VU/RPS). В Apache JMeter этот график называется Response Times vs Threads.

Далее пойдут графики, на которых может быть множество линий, каждая из которых отображает свой сценарий или запрос. Если у вас сложный тест со множеством операций и нелинейным профилем, советуем отражать в отчете лишь наиболее показательные запросы или группы запросов. Как вариант, можно отражать лишь запросы, превысившие SLA/SLO, чтобы не засорять график и отчет.

В MF LoadRunner график называется Average Transaction Response Time и показывает среднее время для транзакций
Для Apache JMeter график существует в двух вариантах в расширенном пакете с сайта JMeter-Plugins.org и называется Response Times Over Time и, по умолчанию, Response Time Graph. Более наглядный и удобный, на мой взгляд, первый вариант

Вариации графика

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

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

HTML Gatling Report
Для MF LoadRunner график будет называться Transaction Response Time (Percentile)
Также вы можете получить и перцентили для Apache JMeter с помощью графика Response Times Percentiles из этого же расширенного набора

Распределение Response Time

Также есть прекрасные графики, показывающие зависимость распределения времени от количества запросов.

Этот вид графиков чем-то напоминает индикаторы, но показывает более полную картину распределения времени, без обрезки перцентилями или другими агрегатами. С помощью графика можно более наглядно определить границы для групп индикаторов. У MF LoadRunner такого графика нет.

HTML Gatling Report для каждого запроса
Есть еще один вариант распределения времени выполнения запроса от количества запросов в разрезе успешных и ошибочных запросов для всего теста
Для MF LoadRunner данный график будет называться Transation Response Time (Distribution) и показывать распределение для транзакций
В Apache JMeter тоже есть этот график в расширенном пакете и называется Response Times Distribution

Latency

Из этой метрики также можно выделить дополнительный параметр Latency (миллисекунды) время задержки (чаще всего под этим понимают Network Latency). Этот параметр показывает время между окончанием отправки запроса до получения первого ответного пакета от системы.
С помощью этого параметра можно измерять также задержки на сетевом уровне, если параметр будет расти. Желательно, чтобы он стремился к нулю. Этот и следующий тип графиков в основном используются при глубоком анализе и поиске проблем производительности. Этого графика из коробки нет в Gatling. В MF LoadRunner этот график называется Average Latency Graph в блоке Network Virtualization Graphs если у вас установленные агенты мониторинга.

В Apache JMeter этот график присутствует лишь в расширенном наборе и называется Response Latencies Over Time

Bandwidth

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

Изменяя этот параметр на инструменте нагрузки можно моделировать различные источники подключений к приложению: мобильная связь 4G или проводная сеть. В бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Этот график из коробки есть лишь в MF LoadRunner, находится в том же блоке, что и Latency, и называется Average Bandwidth Utilization Graph.

График Request Per Second

Измеряется в штуках в секунду показывает количество запросов, поступающее в систему за 1 секунду.

График показывает, сколько запросов может выдержать ваша система под нагрузкой, и он является также основным графиком для построения отчета. По нему также отслеживается выход за пределы SLA, так как с ростом нагрузки при прохождении точки деградации или локальных экстремумов может наблюдаться провал, а затем резкий рост. Чаще всего это связано с тем, что, когда приложение начинает деградировать, запросы тоже начинают копиться на входе в приложение (появляется очередь), затем приложение выдает им какой-то ответ или запросы падают по тайм-ауту, что вызывает резкий рост на графике ведь получен ответ.

Если наложить график на VU, можно увидеть увлечение RPS/TPS с увлечением количества пользователей, а также уменьшение в связи с выходом пользователей или стабилизацией подаваемой нагрузки.
Если наложить график Response Time, можно увидеть среднее время, за которое обрабатываются все транзакции или запросы на протяжении теста.

HTML Gatling Report
В MF LoadRunner график называется Hits per Second
Для Apache JMeter существует график Hits per Second из расширенного пакета

TPS

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

Например, транзакция вход в личный кабинет включает следующие запросы: открытие главной страницы, ввод логина, пароля, нажатие кнопки отправить, переадресацию на приветственную страницу в единицу времени. В Gatling график можно получить лишь с помощью применения Grafana, так как для групп в HTML-отчёте строятся графики лишь по времени отклика.

MF LoadRunner Transactions per Second
Для расширенного пакета Apache JMeter Transactions per Second

График Errors

Обычно измеряется в rate (штук в секунду) график показывает рост количества ошибочных запросов. Также удобно измерять значение в процентах от общего числа запросов. По этому графику отслеживается выход за пределы SLA по количеству или проценту ошибок.

Если наложить график Response Time, можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения.

Gatling по умолчанию не имеет отдельного графика, отображающего лишь ошибки. В Gatling он совмещен с графиком VU и сразу показывает, как рост нагрузки сказывается на росте числа ошибок, и помогает обнаружить порог, с которого идет превышение SLA или вообще появляются ошибки. В Apache JMeter также нет отдельного графика, он совмещен с графиками количества транзакций.

HTML Gatling Report
В MF LoadRunner этот график называется Errors per Second

HTTP responses status

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

Например, если на предыдущем графике вы получили 100%, вы начинаете анализировать, а какие именно 50x ошибки из-за того, что сервер не отвечает, или 403 из-за того, что неверный пул и пользователи не могу авторизоваться, если, например, вы используете HTTP-протокол.
Изначально в бесплатной версии Gatling этого графика нет, он есть лишь в платной версии Gatling FrontLine. Чтобы график появился в бесплатной версии, необходимо перенастроить logback.xml так, чтобы логи собирались в graylog, и уже в нем строить нужный график.

В MF LoadRunner этот график называется HTTP Responses per Second
В Apache JMeter этот график называется Response Codes per Second из расширенного пакета

График Throughput

Измеряется обычно в битах в секунду. График показывает пропускную способность приложения, а именно какой объем данных был отправлен и обработан приложением в единицу времени.
Обычно его используют для глубокого анализа проблемы приложений. В Gatling этот график содержится лишь в FrontLine, в бесплатной версии его нет.

Этот график есть из коробки в MF LoadRunner, он называется Throughput
В Apache JMeter график называется Bytes Throughput Over Time из расширенного пакета

Возможные модификации

Если наложить график Response Time, можно увидеть, что рост времени ответа часто связан с увеличением числа отправленных данных (Throughput). Если на графике замечен рост Response Time, а Throughput при этом остается прежним, это указывает на проблемы с сетью или с приложением: где-то начинает копиться очередь запросов.
Если наложить график Bandwidth, то при совпадении объема данных на двух графиках будет видно, что ограничивающим фактором является пропускная способность сети.
Если наложить график VU, то они должны полностью коррелировать, без резких скачков и провалов, так как рост нагрузки должен приводить к планомерному росту объема данных. Расхождения или резкие выбросы являются поводами для дальнейшего изучения.

Получение графиков

Большинство графиков можно получить, используя отчет HTML Based Gatling Reports после теста или же настроив связку мониторинга Graphite-InfluxDB-Grafana. Для отображения можно использовать готовый дашборд из библиотеки дашбордов https://grafana.com/grafana/dashboards/9935.

При анализе и составлении своих дашбордов для Gatling следует учитывать, что результаты в InfluxDB хранятся агрегированные и подходят только для предварительной оценки результатов НТ. Рекомендуется после теста повторно загрузить simulation.log в базу данных и уже по нему строить итоговый отчет и выполнять поиск проблем производительности системы.

Матричное описание метрик

Всё, что мы описали выше, представлено в виде маленькой таблички, суммирующей все эти знания.

Тип	VU	Response Time	Requests	Errors	Throughput
VU	Позволяет сравнить планируемую нагрузку с реальной	Показывает, как увеличение пользователей сказывается на росте времени отклика при закрытой модели	Можно увидеть увеличение RPS/TPS/HITS с увеличением количества пользователей, а также уменьшение в связи с выходом пользователей или стабилизацией подаваемой нагрузки	Показывает, при каком числе VU происходит рост ошибок. Не всегда показателен, так как в открытой модели сложно коррелировать графики	Метрики должны полностью коррелировать, так как рост пользователей приводит к росту объема данных, отправляемых ими. Расхождения или резкие выбросы являются поводами для дальнейшего изучения
Response Time		Показывает, как быстро сервер отвечает на наши запросы. Основная метрика	Показывает среднее время, за которое обрабатываются все транзакции или запросы на всем протяжении теста	Можно увидеть, как увеличение ошибок влияет на рост времени ответа приложения	Рост времени ответа часто связан с увеличением количества отправленных данных (Throughput). Если на графике замечен рост Response Time, а Throughput при этом остается прежним, это указывает на проблемы с сетью или с приложением: где-то начинает копиться очередь запросов
Requests			Показывает, сколько запросов выдерживает система в секунду, минуту и т. д.	Позволяет найти значение интенсивности, после которой появляются ошибки. Удобно для определения SLA	Позволяет контролировать рост объема данных и количества запросов. Эти метрики должны коррелировать. Появление проблем может свидетельствовать, что мы отправляем неверные запросы
Errors				Позволяет оценить рост числа ошибок и тип ошибок, которые проявляются под нагрузкой	Можно найти объем данных, при котором приложение начинает генерировать ошибки
Throughput					Показывает, какой объем данных приложение может прокачать через себя за заданный промежуток времени

Подробнее..

Категории: Высокая производительность , Тестирование it-систем , Тестирование веб-сервисов , Нагрузочное тестирование , Gatling , Блог компании tinkoff , Performance testing , Jmeter , Loadrunner

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

07.01.2021 14:19:53 |

Автор: admin

Если вы создаёте приложение, которое должно масштабироваться а все мы надеемся, что наши приложения будут расти то в определённый момент нам приходится разбираться, может ли оно это делать на самом деле. Именно тогда на помощь приходит нагрузочное тестирование: если вы хотите узнать, справится ли ваше приложение с крупными масштабами, то мы просто генерируем эти масштабы и проверяем! Звучит достаточно просто.

Но потом мы пробуем действительно сгенерировать нагрузку. Это делается легко, только если ваше приложение ужасно простое, ведь тогда можно использовать что-нибудь типа Apache JMeter для генерации повторяющихся запросов. Если у вас это получится, то я вам завидую: все системы, с которыми мне приходилось работать, сложнее и требовали более изощрённой схемы тестирования.

Если ваше приложение становится чуть сложнее, то вы переходите к инструментам наподобие Gatling. Они позволяют симулировать виртуальных пользователей, выполняющих различные сценарии, что намного полезнее, чем простая осада одного или нескольких URL. Но даже этого недостаточно, если вы пишете приложение, использующее одновременно WebSockets и HTTP-вызовы в течение долговременной сессии, а также требующее повторения по таймеру определённых действий. Возможно, я серьёзно недоглядел чего-то в документации, но мне не удалось найти способа, допустим, настроить периодическое событие, запускаемое каждые 30 секунд и выполняющее определённые действия при ответе на сообщение WebSocket, а также производящее действия по HTTP, и всё это в рамках одной HTTP-сессии. Я не нашёл такой возможности ни в одном инструменте нагрузочного тестирования (и именно поэтому написал на работе свой собственный инструмент, который надеюсь выложить в open source, если найду время на подчистку кода и отделения его от проприетарных частей).

Но предположим, что у вас есть стандартный инструмент наподобие Gatling или Locust, который работает и удовлетворяет вашим нуждам. Отлично! Теперь давайте напишем тест. По моему опыту, сейчас это самая сложная задача, потому что нам сначала нужно разобраться, как выглядит реалистичная нагрузка вас ждёт один-три дня кропотливого изучения логов и ведения заметок по показателям сетевых инструментов в браузере при работе веб-приложения. А после того, как вы узнаете реалистичную нагрузку, то вам придётся написать код, который сводится к следующему: подмножество вашего приложения будет притворяться пользователем, общаться с API и выполнять действия, которые совершает пользователь.

И на этом ещё ничего не закончилось! Здорово, мы написали нагрузочный тест, и он реалистичен. Но задача постоянно меняется, ведь выпускаются обновления. То есть теперь у нас появилась проблема поддержки: как обеспечивать актуальность нагрузочного теста при изменении приложения? Для этого нет качественных инструментов и почти ничто вам не поможет. Придётся сделать это частью процесса и надеяться, что вы ничего не упустите. Такой ответ не радует, и именно поэтому этот аспект является одним из самых сложных при тестировании приложения.

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

Откуда берётся сложность

По сути, ситуация такова:

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

Давайте подробно рассмотрим каждый из пунктов, и разберёмся, от какой степени сложности можно избавиться.

Симуляция пользователей. Действительно ли она нужна?

Здесь я могу ответить да, хотя это может зависеть от конкретного приложения. В данном случае подразумевается пользователь сервиса: если у вас монолит, то это все ваши пользователи, но в случае микросервисов пользователем может быть один из сервисов! При создании приложений, над которыми я работал, мне удалось достичь незначительного успеха с таргетированными тестами отдельных конечных точек. Но в конечном итоге для этого требовалась такая сложная система, что это оказалось ненамного проще самого нагрузочного теста! И хотя мы получили некоторые результаты и усовершенствования, покрыть всё не удалось (в приложении могут быть взаимодействующие конечные точки) и мы не смогли получить реалистичную нагрузку.

Лучше задаться вопросом: А когда не нужно симулировать пользователей?. Насколько я понимаю, такое бывает, когда вы знаете, что все конечные точки независимы по производительности, отсутствуют запросы с отслеживанием состояния и порядок запросов не влияет на производительность. Это довольно серьёзные допущения, и без проверки их независимости сложно быть уверенным в них, поэтому нам приходится возвращаться к написанию теста.

Вероятно, лучшее, что вы можете здесь сделать, происходит на этапе проектирования API и системы, а не на этапе тестирования. Если упростить API, то тестировать придётся гораздо меньшую площадь поверхности. Если спроектировать систему с более независимыми частями (например, когда у каждого сервиса есть своя база данных), то их проще будет тестировать по отдельности, чем монолит. К тому же, при этом вы сможете использовать более простой инструмент двойная выгода!

Написание тестов сложная задача. Как и их поддержка.

Создавать тесты сложно, потому что требуется выполнить несколько задач: нужно разобраться, каков поток использования API и написать симуляцию этого использования. Для понимания потока необходимо понимание других систем, кроме тестируемой, и поскольку ваша система вряд ли подробно рассматривается в их документации, не будет чёткой диаграммы того, когда и что вызывается; часто приходится разбираться в логах, пока не поймёшь, какова же истинная схема использования. Далее идёт написание этой симуляции тоже нетривиальная задача, поскольку необходимо обрабатывать состояние большого количества акторов, представляющих собой пользователей вашего API!

А, да, и теперь вам нужно писать для всего этого ещё и интеграционные тесты.

Существуют исследования о том, как упростить некоторые из этих задач. Например, можно разобраться в том, что вам нужно для первоначального теста, и распознавать регрессии (отсутствующие новые нагрузки) по автоматизированному анализу логов. Но насколько я понимаю, на GitHub, не говоря уже о коммерческой доступности, нет продукта, способного выполнить за меня эту задачу. Поэтому похоже, что в нашей отрасли подобные системы не получили широкой поддержки. Для самостоятельной реализации этот проект был бы слишком большим, и в этом может быть причина его увядания (или он реализуется в больших компаниях и о нём не говорят).

Может быть, не подвергать всё нагрузочному тестированию?

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

Чтобы получить подробную картину производительности системы, можно воспользоваться одним из способов:

Старый добрый анализ. Усесться с ноутбуком, ручкой и пониманием системы в целом, выделить на это полдня, и вы получите примерные расчёты основных параметров и ограничений масштабирования системы. Когда вы наткнётесь на бутылочное горлышко или встретитесь с неизвестными переменными (сколько транзакций в секунду может поддерживать наша база данных? Сколько мы их генерируем?), то можно будет протестировать конкретно их!
Разворачивание фич. Если вы можете медленно разворачивать фичи на всех пользователей, то вам может и не понадобиться нагрузочное тестирование! Вы можете измерять производительность экспериментально и проверять, достаточно ли её. Достаточно? Разворачиваем дальше. Мало? Откатываемся назад.
Повторение трафика. Это совершенно не поможет с новыми фичами (для них воспользуйтесь предыдущим пунктом), но поспособствует пониманию критичных точек системы для уже имеющихся фич, при этом не требуя большого объёма разработки. Вы можете взять отслеженный ранее трафик и повторять его (многократно снова и снова, даже комбинируя трафик различных временных периодов), наблюдая за производительностью системы.

На правах рекламы

Серверы для разработки это эпичные от Вдсины.
Используем исключительно быстрые NVMe накопители от Intel и не экономим на железе только брендовое оборудование и самые современные решения на рынке!

Подробнее..

Категории: Высокая производительность , Тестирование it-систем , Тестирование веб-сервисов , Нагрузочное тестирование , Gatling , Блог компании vdsina.ru хостинг серверов , Нагрузочные тесты , Apache jmeter

Как мы тестировали web систему с требованием в 42 000 пользователей

07.06.2021 08:09:22 |

Автор: admin

Web-система. Ver 1.0

К нам обратился клиент, который хотел выполнить тестирование своей системы на возможность выдержать работу 42 000 пользователей. Они представили нам свой продукт и требования работы данного продукта:

Опросник международного уровня;
Содержал около 5 вкладок для перехода и переключение языка;
Срок работы опросника всего неделю, но судя по требованиям он должен был быть максимально стабильным и работать безотказно;
Ручное время выполнения сценария пользователем должно было составлять примерно 50 - 60 секунд по заявлениям заказчика.

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

И так, что же было у них под капотом:

Каждый переход по вкладке динамически загружал данные по технологии WebSocket;
На странице использовался JS, CSS;
Около 50 - 60 картинок;
Файл языкового пакета.

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

У нас новомодная технология и наша система высокопроизводительная... ?!

И так получив систему, мы были ознакомлены и с предоставляемым профилем нагрузки (клиент хочет, клиент платит - кто мы такие, чтобы спорить). Профиль нагрузки был амбициозный: начинаем с 625(!!!) пользователей и добавляем каждые 10 секунд еще столько же. Длительность теста 1 час.

Почему была выбрана цифра 625 для меня до сих пор загадка. Данный тест показал что за час не удалось полностью успешно завершиться ни одному (!) пользователю. Все отработали с ошибками.

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

375 пользователей и добавлять столько же каждые 2 секунды. Длительность выполнения теста 30 минут.

Я не понимаю на что они надеялись поменяв параметры теста таким образом. Но на удивление результат работы был следующим: есть успешно выполненные, но среднее время выполнения сценария около 24 минут. Фактически полностью успешно выполнялись только те, что стартовали вначале.

Провал

В результате клиент был не удовлетворен результатами тестирования. Долгое время выполнения сценария, максимальное количество одновременно работающих пользователей составляло всего 500. Дальше начались отказы в доступе - 503 ошибки сервера.

Не загружались требуемые ресурсы, не загружались динамически изменяемые данные. Все это можно было увидеть пройдя сценарий в ручном режиме при работающем тесте. Заказчики попробовали динамически добавлять сервера, но скорость их развертывания оказалась намного ниже скорости добавления пользователей. Иногда страницы загружались, но без CSS и картинок страницы выглядели примерно как

При таком отображении для рядового пользователя работать было не возможно. В результате тест был признан провалившимся. Web - система не смогла выдержать требуемую нагрузку. Проблема заключалась в том, что данная технология создавала большое количество подключений и удерживала их долго время. И чем больше пользователей прибывало, тем быстрее заканчивались существующие ресурсы. Но заказчику в любом случае необходимо было реализовать web-систему и предоставить ее на всеобщее обозрение.

Web-система. Ver. 2.0

Более недели мы не получали от них никакой информации. Они к нам вернулись с полностью переработанным движком системы.

Дизайн остался старый, те же переходы по вкладкам, те же картинки. Но был выполнен отказ от динамической загрузки данных, отказались от технологии WebSocket. Все необходимые данные загружались при загрузке первой страницы. Переходы по вкладкам были выполнены с помощью JS и отображались исключительно на стороне пользователя системы. Данные теперь отправлялись единожды общим пакетом, когда опрос был полностью пройден и нажата необходимая кнопка. Единственным дополнительным переходом осталась загрузка другого языка при его смене. Таким образом они сократили количество используемых соединений с сервером во много раз.

Мы все переделали. Уж теперь точно полетит?!

Попробовали выполнять более агрессивные профили нагрузки. Сразу запускали 20 000 пользователей, потом 10 000. Но такое большое количество одновременно подключаемых пользователей заваливало сервер сразу же. Новые сервера опять же не успевали загружаться. В результате длительных дискуссий пришли к следующему профилю нагрузки: 150 пользователей и добавлять по 150 каждые 5 секунд. Длительность теста 40 минут.

В результате среднее время выполнения сценария 1 минута 20 секунд. Удалось значительно снизить количество ошибок подключения к Web-системе.

Да, теперь первая страница грузится дольше, чем в первом варианте. Но время выполнения всего сценария сократилось с 22 минут до 1 минуты и 20 секунд. Сервера начинали выдавать ошибки 503 только когда количество одновременно работающих пользователей перешло отметку в 5 000. Таким образом количество пользователей увеличилось в 10 раз с 500 до 5 000.

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

Результат

В результате ими принято решение признать тест успешным. Им не удалось достичь показателя в 50 - 60 секунд на один сценарий, им не удалось достичь 42 000 пользователей. Но они смогли сократить среднее время выполнения сценария и увеличить количество одновременно работающих пользователей в один момент времени.

Заключение

В заключение хочется отметить два момента.

В свете динамических развивающихся frameworkов (react, angular, node, sping и др.), не всегда стоит их применять для разработки продуктов. Порой javascript будет работать намного эффективнее, чем что-то еще. Необходимо инструменты реализации подбирать под задачу, и думать как ваша система будет работать. В указанном мной случае исполнение кода JS на стороне клиента оказалось на много производительнее, чем исполнение кода на стороне сервера от множества пользователей.

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

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

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

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

Подробнее..

Категории: Высокая производительность , Тестирование веб-сервисов , Web , Нагрузочное тестирование

Перевод Нагрузочное тестирование производительности вашего сайта

19.06.2020 20:14:58 |

Автор: admin

И снова здравствуйте. В июле Otus запускает новый курс Нагрузочное тестирование. В преддверии старта курса традиционно делимся с вами полезным материалом.

Поскольку 5 миллиардов человек во всем мире самоизолируются, все больше и больше наших ежедневных взаимодействий происходят через интернет. Ритейлеры по всему миру переводят обслуживание своих клиентов из офисов в онлайн, школы и учебные заведения пытаются находить альтернативы в интернете, и даже общение в кругу семьи переносится на Zoom и Webex вместе с нашими рабочими встречами (с детьми и домашними животными на фоне).

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

Для тех из вас, кто ищет ответы на вопросы о том, как тестировать производительность вашего сайта, чтобы правильно подготовиться к предстоящим неделям, вот 8 советов, которые мы вынесли из работы с нашими клиентами по нагрузочному тестированию за последние 10 лет.

Лучшие советы для успешного тестирования производительности

1. Запускайте нагрузочные тесты из производственной среды

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

2. Масштабируйте свои тесты от маленького к большому и далее к огромному

Если вы очень спешите протестировать большой наплыв пользователей, вы можете случайно пропустить уровень нагрузки, на котором у вас в данный момент могут быть проблемы, потому что вы пропустили слишком много уровней одновременно. Разгоняйтесь понемногу, а затем наращивайте свои тесты все больше и больше. Перед каждым тестом останавливайтесь, чтобы отслеживать результаты, и убедитесь, что вы удовлетворены ими, прежде чем переходить на следующий уровень. В BlazeMeter мы начинаем с отладочного тестирования, которое выполняется как функциональный тест, просто чтобы убедиться, что тест выполняет то, что вы хотите чтобы он выполнял. Затем мы проводим калибровочные испытания. Эта калибровка проводится, чтобы убедиться, что тестовая платформа, на которой выполняется тестирование, на самом деле не является узким местом. Теперь мы можем перейти к гвоздю программы: тестированию производительности. Начните тестирование с 10% целевой нагрузки и постепенно увеличивайте до полной целевой нагрузки. Убедитесь, что разгон постепенный, чтобы вы могли контролировать симптомы.

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

Вот как может выглядеть узкое место. Число попаданий/с падает, а время отклика резко возрастает:

3. Запланируйте тесты

Также вы можете планировать, как выполнять ваши бизнес-цели. Вместе с вашей командой определите, какие тесты вам нужны. Вот типы тестов, которые вы можете запустить:

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

Стресс-тесты стресс-тесты могут помочь вам понять пределы прочности системы.

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

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

Изоляционный тест это повторный тест для проверки, была ли устранена известная системная ошибка или проблема, ранее обнаруженная в этом же тесте.

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

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

4. Мониторинг внутренних результатов нагрузочного теста

Нагрузочное тестирование позволяет просматривать и анализировать KPI производительности, такие как время отклика и латентность, а также корреляции между ними. Но также важно просмотреть ключевые показатели эффективности, такие как Cache Hits и DB Queries, просмотреть лог ошибок на предмет исключений, а также просмотреть стандартные характеристики оборудования, такие как загрузка ЦП/памяти/сети и состояние автоматического масштабирования.

Различные решения расширяют возможности анализа результатов испытаний. DX APM, New Relic, App Dynamics и другие решения обеспечивают мониторинг производительности приложений и мониторинг конечных пользователей, а Amazon Cloud Watch отслеживает облачные ресурсы AWS.

5. Включите отслеживание производительности конечного пользователя в бэкэнд-тестирование

Автоматический или вручную анализируйте то, что испытывают ваши пользователи, благодаря уникальной функции BlazeMeter мониторингу опыта конечных пользователей. Новые возможности функционального тестирования выполняют тест Selenium в фоновом режиме, пока выполняется нагрузочный тест, через Taurus. Тест Selenium создает Waterfall Report, который показывает, что пользователь будет видеть в своем веб-браузере в разные моменты во время нагрузочного теста. Это может быть особенно полезно при отладке, например, из-за того, что определенная страница не была загружена должным образом с точки зрения пользователя в определенный момент нагрузочного теста.

6. Настройте резервные серверы и локации

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

7. Проверьте ваши сторонние интеграции

Когда вы вносите изменения в свое приложение или сайт, вы не просто влияете на свой собственный продукт. Вы также можете влиять на сторонние сценарии в своем приложении или на сайте или же можете вызвать сбой сторонних устройств и серверов, если не подготовите их должным образом. Например, для разных CDN требуются разные подходы, а для балансировки нагрузки AWS (ELB) требуется прогрев перед балансировкой.

Несмотря на то, что это является частью того, что вы тестируете, мы рекомендуем вам заранее связаться с вашими партнерами и провести все необходимые приготовления. Это гарантирует, что нагрузочный тест будет учитывать их подготовку и полные возможности (вместо частичных возможностей, как это может случиться, если у них не будет возможности подготовиться). Это также экономит ваше время и усилия, так как вам не нужно решать распространенные проблемы на стороне, которые можно было бы легко исправить.

8. Внедрить мониторинг API

После того, как вы закончите тестирование, вам все равно захочется узнать, как ваш сайт ведет себя в дикой природе. Вы можете использовать возможности функционала BlazeMeter 360 Degree Monitoring для мониторинга ваших критически важных API-интерфейсов в производственной среде, чтобы убедиться, что ваш веб-сайт или приложение функционируют должным образом. Он будет служить системой предупреждения, чтобы вы знали, когда ваша система работает не так, как от нее ожидают.

Скрытый текст

Хотите прокачать свое тестирование? Подпишитесь на бесплатную онлайн-аккредитацию в университете BlazeMeter здесь.

Готовы начать тестирование производительности вашего сайта? Вы можете бесплатно воспользоваться платформой непрерывного тестирования BlazeMeter и начать тестирование своего сайта в ближайшие несколько минут. Зарегистрируйтесь здесь, чтобы начать тестирование.

Узнать подробнее о курсе.

Подробнее..

Категории: Тестирование it-систем , Блог компании otus. онлайн-образование , Тестирование веб-сервисов , Нагрузочное тестирование , Тестирование сайтов

Из песочницы Вячеслав Смирнов Ускоряем Apache JMeter

11.09.2020 14:12:59 |

Автор: admin

Вячеслав Смирнов Ускоряем Apache JMeter

Apache JMeter не требует рекламы, но нечасто время уделяют скорости работы самих нагрузочных скриптов. Вячеслав рассматривает подходы к оптимальному написанию скриптов, что позволяет сэкономить на нагрузочных машинах и позволяет по-новому посмотреть на JMeter.

Apache JMeter является популярным инструментом тестирования производительности с большим количеством компонентов и возможностей. Одни и те же операции в Apache JMeter можно выполнить несколькими способами.

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

Пользуясь средствами профилирования Java-приложений, такими как Java Flight Recorder, jVisualVM, SJK, имея доступ к исходным кодам инструмента, написав синтетические тесты и взяв примеры из практики, мы подготовили отчёт по тестированию производительности инструмента для тестирования производительности.

Доклад будет интересен инженерам по тестированию производительности, использующим Apache JMeter, как начинающим, так и опытным, а также разработчикам, использующим JVM/JDK в работе и занимающихся профилированием и оптимизацией кода.

Всем привет! Я сегодня расскажу, как ускорить Apache JMeter.

Немного о себе. Я бываю на конференциях в качестве докладчика, в качестве слушателя. Был преподавателем в университете, вел курсы по тестированию, писал статьи на Hubr. Это достоинства.

Но есть у меня и недостатки. Их много. Мне говорят, что я достаточно неторопливый парень, но кое-что я умею делать быстро.

Я ускоряю системы в банках и в других компаниях раньше это делал. И часто это делал с помощью Apache JMeter. Сегодня мы постараемся ускорять с его помощью не какие-то системы, а сам Apache JMeter.

Что такое JMeter, думаю, вы знаете.

Это один из известнейших и старейших продуктов на рынке. Он известен с 2003-го года.
Имеет плагины к более, чем к 50 системам, форматам, способам подготовки и обработки результатов.
Сохраняет статистику в ClickHouse, InfluxDB, Graphite. Многие системы сбора статистики, которые вы видели, отображают это в Grafana или в html-отчете.
Также его удобно встраивать в системы CI/CD.
Он имеет хорошую интеграцию с различными инструментами разработки.
И есть прекрасное сообщество.

Сегодня мы рассмотрим 5 основных тем. Это:

HTTP-запросы. Как сделать отправку HTTP-запросов с максимальной интенсивностью.
Как скачивать и отправлять файлы большого размера. И при этом мы столкнемся с какими-нибудь проблемами.
Также PostProcessor на HTTP-ответы.
PreProcessor.
И расскажу об одном секретном оружие. Это секретное оружие позволит ускорить вообще все.

Моя цель развеять миф, возможно, известный многим, о том, что JMeter тормозит.

А я бы хотел, чтобы вы добились следующих своих целей:

Укрепили свои знания о том, как разрабатывать тест таким образом, чтобы система тормозила, а не тесты.
Как делать так, чтобы запуски тестов были экономными, и вы могли запускать тесты во множестве экземпляров много раз и встраивать это в CI/CD-конвейер, где нужны практически непрерывные запуски нагрузки.
И разрабатывали тесты быстро и просто.

Начнем с самого первого, с HTTP Request максимальная интенсивность.

Samplers.HTTP.Request.X. Простой тест. Несколько GET-запросов на локальный сервер. Для этой проверки я написал простенький скрипт. Назвал его Samplers.HTTP.Request.X. X означает, что он параметризирован. В нем параметризировано все. Сам тест достаточно простой. Давайте разберем из чего он состоит. Он отправляет GET-запросы в цикле и все.

Запуск и остановка nginx в тесте, используя OS Process Sampler

В начале теста и в конце теста я запускаю локальный nginx-сервер. Использую для этого setup-катушку и tearDown-катушку, в которой с помощью OS Process Sampler запускается nginx и в конце останавливается.

Nginx с конфигурацией по умолчанию. Для скорости два процесса вместо одного.

А сердцем теста является одна Thread Group и внутри нее HTTP Request. Я в нем запараметризировал все: на какой сервер отправлять запрос, какую страницу скачивать. И настройки по умолчанию такие, как Use KeepAlive. Она важна, на нее обратим внимание позже.

В данном тесте будем делать короткие сценарии, например, открыть стартовую страницу это один запрос. И будем делать сценарии на 10 запросов открыть стартовую страницу, ввести логин-пароль, или на 100, на 1000 запросов, используя здесь Loop Controller. В нем передавая параметр RequestCount, я могу изменить длину сценария. Таким образом мы сможем проверить, насколько быстро JMeter при разной длине сценария будет работать.

А вверху у Thread Group параметры: сколько потоков это Threads, сколько итераций это LoopCount.

Таким образом сделаем серию экспериментов, в которых будем изменять параметры в трех направлениях:

Количество потоков: 1, 2, 3.
Длину сценария. Короткие сценарии на 1, 10, 50, 100 запросов.
И будем включать-отключать Keep-Alive.

Посмотрим, как изменения этих трех параметров скажутся на производительности.

Изменяя эти параметры, я провел достаточно много тестов. Давайте посмотрим на них.

Если запустить тест только на одном потоке, то мы увидим следующую картину. На тесте с одним запросом (короткий запрос просто открыть страницу) мы видим среднюю интенсивность, которую можно достичь. Это примерно 300-400 запросов в секунду.

Если мы увеличиваем длину сценария, допустим, до 10, то интенсивность возрастает примерно до 4 000 и т. д. по возрастающей.

Понятное дело, что с отключенным Keep-Alive такой опции нет, для нее каждое соединение новое.

При увеличении количества потоков (два потока, три потока) значения, конечно, растут.

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

На что стоит обратить внимание? Зачем я включал и отключал Keep-Alive? Давайте сравним, какой он дает эффект.

Что происходит на тестах, которые состоят только из одного запроса? Все benchmarks, которые я видел на JMeter, состояли как раз из одного запроса. Там ребята брали разные инструменты и добавляли туда ровно один запрос и сравнивали, как JMeter, который выполняет один запрос в цикле, соотносится с другими инструментами, которые делают то же самое.

JMeter, который выполняет только один запрос, не такой уж и быстрый. Даже если просто отключить Keep-Alive он станет быстрее. Мой тест это показывает.

Если сделать тест подлиннее, то включение или отключение Keep-Alive уже практически не играет роли. Они примерно уже равны по скорости.

И вся сила Keep-Alive раскрывается, когда тест достаточно большой, т. е. в 50-100 запросов.

Полезный вывод для тех, кто занимается нагрузкой или пишет benchmarks: Keep-Alive полезен. Он включен по умолчанию. Отключать его не надо. Но вся его сила раскрывается, когда сценарий достаточно длинный, хотя бы больше 10 запросов. Запомним это.

И запомним другой уже несколько негативный момент. Если вы пишите benchmarks на JMeter или на других инструментах, то не делайте их совсем простыми, т. е. из одного запроса. Они получаются слишком короткими. И там происходит избыток соединений, которые лишний раз не закрываются. Это нам снижает максимальную интенсивность.

Самые основные сценарии у нас все-таки состоят не из одного запроса и не из 100, а из чего-то среднего, например, из 10. Это зайти, залогиниться, куда-то перейти, выйти. Примерно это на 10 запросов.

Мы видим, что наш сценарий на 10 запросов выдавал примерно от 4 000 до 5 000 операций в секунду. Но мы видим также, что у JMeter есть достаточно большой потенциал.

Попробуем разогнать наш простой сценарий с 4 000 до 16 000 операций в секунду. А, возможно, даже превысим эти значения. Думаю, у нас получится

Для этого нам понадобятся:

Инструменты мониторинга. Я использовал Telegraf, InfluxDB, Grafana.
Некоторые инструменты, которые позволяют замониторить сетевую подсистему. Для этого есть отличная утилита в Linux это Netstat и другие консольные программы.
Настройки сетевой подсистемы ядра находятся в удобном доступе через файловую систему в Linux: /proc/sys/net/*.
Документация.
Профилировщики: SJK, Java Fligth Recorder.
И настройки самого JMeter.

Изменяя все это, попробуем ускорить с 4 000 до 16 000 наш тест.

Для начала запустим наш эталонный тест на 10 запросов без каких-либо изменений по новой. И замониторим не просто среднее значение интенсивности, а как она выглядела на графике. Я использовал JMeter Backend Listener. И это график из Grafana.

Я ожидал, что интенсивность будет стабильной, т. е. ровно 4 000-5 000. А она не стабильная, она скачет из нижней полки в 500 (на одном запросе) до верхней полочки в 16 000 (на 100 запросах). Видим всплески.

Кроме того, есть ошибки. Например, Non HTTP response code. В данном случае в Linux у меня выдается такая ошибка, как адрес недоступен. В Windows могут быть другие ошибки: невозможно установить соединение. Но у них одна и та же суть.

В данном случае я словил 5,24 % ошибок. И тест уже не совсем успешный.

Если запрофилировать JMeter в этот момент с помощью SJK, то профилирование показывает, что самый долгий метод, т. е. более 64 % это socketConnect. Т. е. JMeter не занимается тем, что отправляет запросы и получает ответы или что-то парсит, или что-то у него внутри медленное. Он занимается тем, что ожидает, что ему дадут новый сокет, чтобы подсоединиться к нашему локальному nginx. И на это тратится большая часть времени работы.

Зная все это, попробуем как-то это ускорить. У нас есть три пути, как у витязя на распутье. Какие это пути?

Мы можем поменять сам скрипт, т. е. что-то изменить в JMeter.
Можем поменять настройки JMeter. Настроек достаточно много, есть что поменять.
И можем поменять настройки операционной системы, т. е. как-то потюнить ядро, потюнить Linux, чтобы он работал быстрее.

Скрипт JMeter: увеличить количество запросов (RequestCount) до 50. Изменим сам скрипт.

Если вы помните, то я начал с того, что мы запускали тесты с разной длиной сценария: 1, 10, 50, 100. И было видно, что когда сценарий достаточно длинный (50 и 100), то нам выдавалось стабильно 16 000 или даже больше запросов в секунду.

Таким образом, если вы столкнулись с этими проблемами и хотите ускорить, то способ ускорения тестов с помощью правки сценария это сделать в нем больше запросов.

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

Может быть, HTTP Cache Manager ускорит работу? Сразу скажу, да, он ускоряет, но у меня тут маленькая оговорка: я загружаю достаточно простой html-документ. Он маленький.

И на маленьком документе, если добавить HTTP Cache Manager, то эффект будет небольшой. Он будет практически незаметным.

Я получил ту же самую интенсивность в 4 800. И получил примерно тот же самый процент ошибок, только чуть-чуть меньший.

JMeter по-прежнему с HTTP Cache Managerом большую часть времени проводит на методе socketConnect. Т. е. мы ожидаем подключение к нашему локальному nginx.

Таким образом в данном конкретном случае модификацией скрипта разогнать тест не удалось, потому что мы решили не удлинять сценарий. У нас по постановке задачи он 10. А HTTP Cache Manager на маленьких ответах нам ничего не дал.

Откатим все изменения назад. Представим, что мы вернулись в прошлое и никаких правок не было, HTTP Cache Manager не добавлялся.

И попробуем какой-нибудь еще вариант. Покликаем настройки самого JMeter.

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

Если сменить реализацию java-клиента (в данном случае я использовал 8-ую Java), то мы получим немалое ускорение в 3,3 раз и не получим ни одной ошибки вообще. Т. е. это практически настройка мечты. Можно ее, конечно, использовать с оговорками, потому что JavaClient может не все то, что поддерживается в HttpClient4. Он раскаченный специально для JMeter. Но если у вас простой HTTP, то почему бы и нет?

В этот момент профилирование показывает, что JMeter уже занялся делом. Большую часть времени он читает ответ. Какую-то часть времени он уже отправляет запросы. Т. е. мы не висим на методе socketConnect. Изменение этой настройки избавило нас от проблемы.

Но откатимся снова в прошлое. Представим, что мы эту настройку не меняли. Поищем какой-нибудь еще способ.

Есть еще одна настройка. Она позволяет отключить сброс состояния между двумя итерациями, т. е. мы выполнили 10 запросов, и там происходит сброс состояния. Мы закрываем все соединения, посылаем TCP закройся, SSL переинициализируйся и начинаем все по новой.

Можно сказать false: не сбрасывай состояние, установил и переиспользуй его.

Попробуем ее поменять. И, о чудо! Тест ускорился практически в 4 раза. В некоторых моментах я превысил даже полочку 20 000 в секунду. И это имея лишь слабенький ноутбук с 4-мя ядрами и три потока. Неплохо, но важно понимать, что эта настройка у нас сократила все-таки некоторое количество соединений, которые мы установили серверу, но она значительно ускорила интенсивность.

Резюмирую по этим двум настройкам. Если заменить реализацию HttpClient4, то мы ускорились на 3,3 раза. А если сделать так, чтобы использовался клиент по умолчанию, но не сбрасывал соединение, то ускорение практически в 4 раза. Неплохой результат.

Но снова откатимся назад. Представим, что мы эти настройки не меняли. И попробуем что-то еще.

А у нас еще есть настройки операционной системы. И там большое количество опций в сетевой подсистеме ядра, которые мы сейчас попробуем задействовать, чтобы наши соединения быстрее возвращались в JMeter, т. е. все было шустрее.

Для этого запускаем тест по новой, но включаем мониторинг всего, что есть. Допустим, я замониторил nginx. Видим, что подключения к nginx идут достаточно интенсивно, т. е. интенсивность подключения скачет от 0 до 1 200-1 300-1 400. И в пике получается, что максимальная планка подключений в секунду примерно в 10 раз меньше, чем от интенсивности в тесте. Это логично. Мы делаем 10 запросов подключение, 10 запросов подключение. Т. е. графики коррелирует.

График утилизации процессора, где красная линия это системное время, а синяя линия пользовательское время. А все остальные линии это waits и что-то еще. И график показывает, что конфигурация по умолчанию большую часть времени тратится как раз на системные вызовы, а пользовательский код проигрывает в 3,5 раза.

Значит, обратим внимание на различные системные метрики. Прежде всего на сетевые. И мониторинг метрик, который в Grafana, Telegraf называется Netstat, в частности, метрика tcp_time_wati, показывает, что с момента начала теста мы достаточно быстро доходим до полочки, которая отчетливо вырисовывается в 28 231. Вот такое магическое число. И держимся на этой полочке весь тест. Иногда лишь прогибаясь, но потом возвращаясь. Т. е. что-то нас держит, ограничивает значение tcp_time_wait этим числом.

Чтобы замониторить, кто подсоединяется к нашему локальному nginx (я локальный nginx запускал на локальном порту 5555), используем утилиту NetStat.

Она показывает, что там лишь одно соединение от JMeter к nginx установлено, а все остальные находятся в состоянии TIME_WAIT. Т. е. все эти 28 000 это JMeter установил соединение, потом итерация закончилась, и он сказал: Соединение закройся. И теперь соединение ожидает, когда nginx ему подтвердит: Да, я соглашаюсь, давай закроемся, т. е. происходит некое согласование. Оно происходит не мгновенно, поэтому какое-то время соединение в этом состоянии висит.

Поиск по документации быстро нас выводит на опцию, которая отвечает за количество соединений, которые мы можем открыть. Она называется local_port_range. Ее значение по умолчанию в Ubuntu от 32 000 практически до 61 000.

И если из 61 000 вычислить 32 000, то мы получим наши 28 000.

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

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

Допустим, отодвинем левую границу в 32 000 еще левее и сделаем наш диапазон несколько больше, т. е. в два раза: от 1 025 до 60 999. Совсем до нулей отодвигать не стал, потому что не знаю, к каким последствиям это привело бы.

Очень мне помог @blog.kireev.pro. Там очень хорошо описано, что такое tcp_time_wait и почему это возникает, и что с этим делать.

Мы меняем настройку. Перезапускаем тест. И у нас есть ускорение примерно в 1,6 раза. Теперь интенсивность скачет не от 500 до 16 000, а от 3 500 до 19 000. Это уже хорошо. Средняя составила 7 700.

Ошибки ушли, что немало важно. Практически победа.

Если посмотреть профилировщиком что же сейчас выполняет JMeter, он по-прежнему висит на методе socketConnect.

Мы ускорились, избавились от ошибок Address not available за счет опции ip_local_port_range.

Но мы лишь полечили симптомы, проблема осталась, мы все еще висим на socketConnect. И если обратно вернуться на метрику Netstat: tcp_time_wait, т. е. замониторить ее с помощью Telegraf, посмотреть Grafana, то мы видим, что мы больше не упираемся в 28 000. Мы теперь упираемся в 32 768. Снова замечательное число, думаю, знакомое айтишникам. И что-то нам подсказывает, что это очередной лимит.

И, наверное, мы можем его найти. Такой лимит есть. И есть такая опция tw_ buckets максимальное значение, максимальная длина очереди TIME_WAIT.

Если снова выполнить команду cat, она подскажет, что в Ubuntu по умолчанию значение как раз равно 32 768.

И мы его можем изменить, допустим, в два раза, записав туда значение в 65 000. Давайте это сделаем.

Перезапустим тест, но увы, нагрузка осталась той же. Среднее значение примерно то же. Она по-прежнему скачет от 3 500 до 19 000.

Какие плюсы? Tcp_time_wait упирался в полочку в 32 768, а теперь он не упирается. Он вначале заскакивает на 46 000. И по ходу теста плавает в более свободном интервале, т. е. полочки нет, но разогнаться нам это не помогло.

Запомним этот момент. Это опыт. Если увеличить local_port_range, а потом сверху, не откатываясь назад на машине времени еще увеличить tw_buckets, то tw_buckets как-то не добавляет нам ничего хорошего, но мы уходим от полочки. И это плюс.

Профилирование показывает, что с двумя настройками JMeter по-прежнему висит на методе socketConnect, но уже меньшую долю около 50 %. Будем искать настройки дальше.

И поиск по настройкам нас приводит к тому, что можно переиспользовать TIME_WAIT-соединение. Для этого нужно записать 1 в настройку tcp_tw_reuse. По умолчанию там 0.

Если это сделать, то интенсивность на данной машине без каких-либо правок теста, без каких-либо опций увеличивается в 3,6 раза и достигает 19 000 иногда. Становится более стабильной. Конечно, мы избавляемся от ошибок.

Профилирование показывает, что JMeter уже занялся делом. Он делает socketRead, иногда socketWrite, т. е. делает осмысленные действия. Теперь мы читаем заголовок ответа и тратим на это большую часть времени.

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

Но снова упираемся в подозрительную полочку по TIME_WAIT. Но на данный момент мы уже выполнили все наши задачи. Если изначально задача была побить планку в 16 000, то мы ее побили. Какая такая есть настройка, которая нас ограничивает в 30 000, я не знаю, но есть хорошее руководство у других инструментов по тестированию производительности. Например, Gatling.

https://bit.ly/gatling-tuning

https://gatling.io/docs/current/general/operations/

Это можно найти в документации Gatling, в разделе General/ Operations. Там есть настройки по Java и тюнинговым операционным системам.

Некоторые из них пересекаются с теми, которые я уже успел использовать. Например, local_port_range.

Но эти настройки нужно использовать по одной и с осторожностью. Почему? Например, некоторые настройки, рекомендации говорят, что в 5, 6 строчках мы увеличим максимальное количество файлов, которые доступны на данной системе. Но по секрету скажу, что в операционной системе Linux настройка nr_open по умолчанию равно миллиону. И если бездумно выполнить рекомендацию, то мы ее не увеличим, а понизим до 300 000.

Вторая настройка file-max ровна 70 000 с лишним, и мы ее понизим. Поэтому нужно внимательно смотреть на рекомендации, по одной применять и тем или иным способом вы ускорите работу.

Там есть хорошая настройка tw_reuse = 1.

https://yandextank.readthedocs.io/en/develop/generator_tuning.html#tuning

И есть хорошая рекомендация от Yandex.Tank. Они тоже пересекаются, их тоже нужно смотреть по одной, внимательно читая.

Например, там есть некоторые старые настройки tw_recycle. Tw_reuse рекомендуется выставить в ноль. Думаю, у разработчиков Gatling были свои причины, чтобы сделать так. Возможно, эти две настройки на другой версии ядра давали тот же самый эффект.

Смотрите настройки Yandex.Tank, Gatling, вы можете еще что-то дополнительно затюнить, мы уже в эти подробности вдаваться не будем.

Пока остановимся на том, что tw_reuse позволил нам в 3,6 раза ускорить тест. И это здорово.

Если посмотреть на все настройки целиком, то что получилось?

Если не сбрасывать состояние, а выставить значение reset_state в false, то мы ускорились 3,9 раза.
Если сменить Httpsampler на стандартную реализацию Java, то в 3,3 раза.
А по настройкам Linux c tw_reuse в 3,6 раза при наличии всех других настроек.
И local_port_range в два раза нам все-таки ускорило тест.

Прошу обратить внимание на опции из других инструментов. Они нам пригодятся.

Вы можете увидеть, что состояние нормальное у JMeter это не когда он висит в методе в socketConnect. А когда он примерно треть висит в read. 20 % он выставляет timeout это некие сервисные функции. 11 % в BackendListener. И 12 % отправляет запросы. Вот это состояние нормального и здорового JMeter.

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

А мы пока перейдем к следующей части. Это как скачивать файлы большого размера в JMeter, во что мы упремся при этом и как мы это ускорим.

Последовательное скачивание файла, используя Thread Group на один поток и 200 итераций, имея 4 Гбайт Heap Size

Для этого теста я придумал такую задачу, что мы будем скачивать 200 гигабайт последовательно. Создается один поток и в нем 200 раз скачивается гигабайт. И посмотрим, как JMeter справляется, и с какими ограничениями мы столкнемся.

Файл точного размера 1 гигабайт. Я его создал с помощью утилиты DD. Думаю, все ей доверяют.

Запускаем тест с настройками по умолчанию. И получаем неплохой результат. 5 минут. Скорость загрузки каждого гигабайта достаточно стабильна. В целом 1,5 секунды. Но мы употребили всю память, которую я выделял по JMeter. Я выделял 4 гигабайта.

Если посмотреть с помощью Java Fligth Recorder, как утилизируется память, то вот этот синий график показывает, что память постоянно выделяется и очищается, т. е. сборок мусора за время скачивания этих 200 гигабайт было неимоверное количество. А средний memory traffic (метрика отображается в правом нижнем углу данной вкладки) показывает, что мы примерно выделяли память со скоростью 2 гигабайта в секунду. Т. е. JMeter скачивал 200 гигабайт и каждую секунду выделял 2 гигабайта, а JFR их очищал. Думаю, был большой overhead только на JFR.

Профилирование с помощью SJK показывало, что мы висели на socketRead, т. е. читали, выделяли память, очищали.

Важно заметить следующую штуку. Если хоть чуть-чуть увеличить размер файла, имея Heap в 4 ГБайта, допустим, я скачивал 1 гигабайт, а буду скачивать 1,1 гигабайт, то сразу получаю OutOfMemoryError. Это соотношение важно запомнить. Я думаю, что если скачивать 2 гигабайта, то мне нужно HEAP 8 гигабайт, т. е. большой объем памяти нужно на нагрузочной станции, чтобы скачивать большие документы с настройками по умолчанию.

Запомним этот опыт, как несколько негативный. Httpsampler с настройками по умолчанию работает быстро, но требует гигантское количество оперативной памяти.

И на этой неутешительной ноте, я думаю, что у нас есть три пути, чтобы как-то это исправить.

Изменить скрипт, изменить настройки операционной системы или изменить настройки JMeter.

Начнем с того, что изменим скрипт.

Документация по HTTP Request подсказывает нам, что есть такая опция Save response as MD5 hash. Что она позволяет? Она позволяет не сохранять все тело ответа, а превратить его в MD5 hash. И мы, я думаю, сэкономим на памяти. Т. е. мы уже не будем хранить столько всего.

Поставим ее, запустим тест. И, правда, мы память сэкономили. Утилизация памяти стала равна нулю. Но мы несколько удлинили сам процесс скачивания, т. е. аж до 18 минут. Среднее время теперь составило 5,5 секунд на гигабайт.

Если запустить Java Flight Recorder, то он покажет, что мы вообще не видим синюю линию. Т. е. память с начала теста чуть-чуть выделилась и тут же ее сборщик мусора очистил ее все. Памяти действительно ноль, ее нет.

Профилирование показывает, что MD5 занял 66 %, т. е. в два раза больше, чем оставшуюся часть. 33 % socketRead. Таким образом, если поставить галочку MD5, то мы замедляем наше скачивание ровно в три раза. К нашему одному socketRead добавляется две части на MD5.

Запомним все-таки MD5 как компонент, который не врет. Там написано, что он сокращает утилизацию памяти. Он ее сокращает до нуля, но он замедляет скачивание до трех раз.

Откатим эту настройку назад, представим, что у нас снова эталонный скрипт.

Мы скачиваем наши 200 гигабайт, но зададим себе следующую задачу как скачать и быстро, и потратив немного памяти? Есть ли такой способ в JMeter? Думаю, многие скачивали гигабайты с помощью консольных утилит: wget, curl. И с помощью OS Process Sampler консольные утилиты и скрипты можно легко встраивать в JMeter. Давайте так и поступим.

Для этого я написал несложный скрипт. Это для Linux, который использует wget. Назвал его wget-download.sh. В него передаются параметр url. И он скачивает, отправляя весь результат в dev/null, чтобы у меня на нагрузочной станции диск не переполнился. Если проводить 2-3 итерации теста, то 400-600 гигабайт и все, станция потеряна.

Тот же самый скрипт можно написать и для Windows. Wget с помощью MinGW. Dev/null только в Windows выглядит иначе.

Кроме того, Wget может ограничить и скорость скачивания. Мы можем притвориться, допустим, мобильным клиентом.

Это аналог опции characters per second, которая есть в JMeter, но она там задает ограничение на весь JMeter в целом, а Wget мы можем сказать, чтобы конкретный запрос скачивался медленно, а другой запрос быстро, т. е. это несколько удобнее.

Кроме того, мы можем добавлять заголовки. Можем сказать, что мы поддерживаем gzip.

И даже этот gzip можем разжимать с помощью gzip. Т. е. bash утилиты дают нам полную свободу. Мы можем действовать как отличный консольный клиент.

Но чтобы это выглядело в JMeter как родное, нужно воспользоваться некоторой хитростью. Я ей воспользовался. Она называется SampleResult. Есть программный доступ из PostProcessor, который позволяет BodySize установить, content-type, все заголовки заполнить.

И если им воспользоваться, то в JMeter будет видно все, что выводит Wget в качестве body. Я не стал сохранять все тело ответа.

И все заголовки. SampleRusult позволяет встраивать всякие консольные штуки.

Запустим этот тест с wget. Он нам показывает на данный момент победный результаты: 0 мегабайт утилизации памяти и всего лишь 2 минуты.

Таким образом, если смотреть на все три наших запуска, то:

Стандартные настройки 5 минут,
Включили галочку получили 18 минут,
Использовали wget 2 минуты.

Запомним, что OS Process Sampler + JSR-223 с положительной стороны. Они нам решили задачу, ускорили. По сравнению с MD5 даже ускорили в 7 раз. Хорошая связка.

Откатим и эти настройки назад.

Попробуем теперь ускориться за счет настроек JMeter.

Есть такая настройка, которую будем считать секретной. Она в документации особо не описана, но ее можно найти в JMeter properties. Она ограничивает максимальное количество байт, которое Sampler будет хранить из ответа. Ее значение по умолчанию 0. Это означает, что если пришел гигабайт, я его скачал, то и гигабайт буду хранить.

Выставим ее в 100, чтобы хранить только 100 байт.

Запустим тест. И это практически победа. Мы ускорились до 1 минуты. Съели не очень много памяти 180 мегабайт. А среднее время было практически на протяжении всего теста стабильным и не превышало 500 миллисекунд на файл.

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

Но нужно знать, что MD5 hash замедляет тест. Можно уйти вообще в консольные инструменты интеграции. И, допустим, с помощью wget получить 2 минуты. Или использовать некий хак, например, скачать гигабайт, но сохранить только часть этого гигабайта. И получить самое максимальное ускорение. В данном тесте у нас опции JMeter победили всех.

Вы можете попробовать их как-то смешать, но их особо не смешаешь, они все слишком разные, потому что MD5 и так сжимает тело. Wget вообще практически ничего не скачивает. А ограничение времени ответа само по себе.

Итак, мы разобрали, как скачивать с максимальной интенсивностью это первый момент.

Второй момент как скачивать большие файлы. И теперь давайте разберем, как отправить большие файлы, но только быстро.

Я сразу скажу, что отправка больших файлов в JMeter достаточно шустрая. Ее как-то особо тюнить не надо. Главное, воспользоваться главной вкладкой. Она называется Files Upload. И эта вкладка позволяет больше, чем видно на первый взгляд.

В ней есть неочевидный секретный вариант. Здесь, чтобы упростить вам взаимодействие с непростым интерфейсом HTTP Request, я сделал вот такую схему.

Обозначил способ задания параметра через Parameters. Этот способ по умолчанию солнышко. Думаю, это любимый многими вариант.

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

А шустрые и выносливые способы это Files Upload. Это лошадка. И секретный единорог, если мы заполнили не все параметры, а только один путь к файлу. Если мы заполнили только путь к файлу, то загружается все тело запроса, а не один параметр.

И они комбинируются следующим образом. Parameters и Files Upload комбинируются между собой.

А Files Upload (body data) и Body Data не комбинируются ни между собой, ни с кем-либо еще. Вот это важно запомнить. Если вы попробуете их как-то скомбинировать, то вам JMeter покажет ошибку, так он не умеет.

Можно задавать как один параметр, при этом неважно, что будет стоять в опции Use multipart/form-data. Если что-то заполнить, то будет всегда form-data.

Можно заполнять несколько параметров.

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

И если я захочу первый запрос отправить с текстом Маша, второй Саша, а третий Петя, а у меня один файл? Что можно предложить?

Как готовить файлы большого объема, например, 10 гигабайт, если вам нужна и скорость, и динамичность? Я использую следующий подход в работе.

Допустим, мне нужно отправить 10 гигабайт файлов и это JSONs. Я заранее готовлю эти JSONs. И оставляю там какой-нибудь якорь. Допустим, номер счета или название организации. Это переменная.

Упаковываю это в архив. И перед отправкой использую следующую штуку. Распаковываю архив и применяю утилиту Sed. Она работает максимально быстро и это в 100 раз быстрее, чем если бы мы компоновали 10 гигабайт строк или файлов с помощью Java или чего-то еще. Мы все это сделали на диске, не тратя память.

Итог по отправке файлов: пользуйтесь вкладкой Files Upload, где можно загружать не только параметры, но и тело целиком и консольными инструментами.

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

Для этого теста я выбрал стартовую страницу JMeter. Будем парсить из нее hint к этой стартовой картинке.

Тест на Boundary Extractor. Я его навесил на константный JRS223 Sampler, который ничего не делает, но загружаю не сайт Apache JMeter, этот html-контент, а из переменной. Назвал ее html-контент. И она вот здесь располагается в особом поле для переменных, т. е. http-запроса нет. Чистое использование Extractor.

Такой тест есть для Boundary Extractor, регулярки.

JSR-223 PostProcessor, который повторяет Boundary Extractor.

BeanShell PostProcessor, который повторяет Boundary Extractor.

Есть CSS Extractor.

И XPath Extractor в режиме tolerant parser. Особую галочку ставишь, и тогда XPath может парсить и html.

Сравним их. Получаем следующие результаты довольно предсказуемые.

Boundary, который просто ищет тест между правой и левой границей всех победил с результатом более 55 000 запросов в секунду.

На втором месте с результатом в 50 000 запросов в секунду регулярки.

Потом JSR223 и BeanShell. JSR223 быстрее, потому что он компилированный.

Мой любимый CSS Selector проиграл.

А XPath проиграл совсем. XPath не используйте.

Общее влияние PostProcessorов небольшое

Я уже было расстроился, что CSS Selector проиграл, но он не такой плохой. Если сравнить, как соотносится CSS Selector с некими внутренними вещами в JMeter, допустим, с записью логов, то он всего лишь в два раза дольше, чем запись логов. А запись логов мы не отключаем, поэтому CSS Selector можно тоже использовать, но особо там не накручивая по 200 CSS Selectors. 3-4 добавили и хватит.

Точно не надо использовать tolerant parser и XPath. Нужно использовать регулярки и Boundary Extractor. Или CSS Selector, но помня, что он имеет свою цену.

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

По PreProcessors совсем коротко.

В одном из тестов, где мне нужно было готовить тело запроса для тела в виде XML для HTTP-запроса я использовал Groovy PreProcessor и писал там, используя SimpleTemplateEngine, хорошую XML.

Выбор пал на SimpleTemplateEngine из всех возможностей подготовки XML, потому что я попал в ментальную ловушку. Мне показалось, что SimpleTemplateEngine простой, поэтому, наверное, будет быстрым, а все другие называются XML.MarkupBuilder это сложно и, наверное, они медленные.

Я так написал, как сумел ускорил. И жил себе не тужил. А потом пришли ребята, мои коллеги, и просто переписали на XML.MarkupBuilder, и весь тест ускорился в 5 раз. Все оптимизации можно было выкинуть, потому что все залетало.

XML.MarkupBuilder просто волшебен. Он позволяет строить XML, параметризируя все, что угодно, добавляя атрибуты динамические, в цикле накидывать динамическое количество узлов в XML. И позволяет задавать атрибуты этих подузлов с помощью переменных или тестовые значения с помощью переменных. Groovy нам раскрывает широкие возможности.

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

Таким образом, если есть частая задача готовить XML в PreProcessors, то обратите внимание на MarkupBuilder. И документация на него на сайте Groovy хорошая. Он очень быстрый. Позволяет сэкономить много времени.

Мы закончили 4 основные момента. И теперь я расскажу про секретное оружие.

Секретное оружие позволяет:

Разрабатывать скрипты на JMeter быстро,
Быстро скачивать расширение библиотеки и не думать о версиях,
Быстро запускать профилирование тестов, подготавливать данную презентацию. Я сделал, наверное, более 100 запусков. Подготовил 100 отчетов, запрофилировал все это, выбрал некоторые интересующие. Я потратил на это не 10 лет жизни.
И не терять ни одно изменение, потому что все будет гитоваться на каждую станцию, у каждого нагрузочника будет одна и та же версия вплоть до коммита.

Что это за секретное оружие? Это связка из трех богатырей: Maven, jmeter-maven-plugin и IntelliJ IDEA. Они позволили за последние два года ускорить мою работу раз в 10.

В чем их преимущество?

IntelliJ IDEA имеет колоссальное количество дополнений. И одно из них касается JMeter. Оно позволяет подсвечивать синтаксис.

Какие есть фишки в IDEA? Там можно быстро искать текст, заменять его, выполнять refactoring. Таким образом, если мы вдруг ошиблись с названием переменной, например, html-content решили переименовать просто в html, то мы быстро делаем refactoring. И он во всех скриптах, во всех настройках меняется. Мы нигде и ничего не забудем. Если кто-то выполнял refactoring в сложном JMeter-скрипте, то знает, что это не просто.

И, кроме того, в IDEA хорошая интеграция с git. Она все загитует.

Если нужно добавить плагин в JMeter, то как обычно мы это делаем? Мы скачиваем плагин, кладем его в библиотеку. И потом таскаем эту папочку с библиотечками и плагинами от станции к станции, чтобы не потерять. Это плохой вариант.

Можно сделать более изящно и хранить с помощью jmeter-maven-plugin только лишь название плагина, и он будет скачиваться автоматически.

То же самое касается и любых библиотек. Их можно указывать явно в разделе testPlanLibraries.

Либо можно еще сократить себе время и указывать только название основной библиотеки, а для всех ее зависимостей сказать: Maven, найди и скачай сам. И все скачается.

Кроме того, Maven за счет использования профилей и Properties позволяет, не запуская JMeter, не меняя ничего в коде, переопределить все, что угодно в скрипте.

Допустим, я менял количество итераций, сколько мне нужно скачать файлов, сам путь к файлу, предварительно создавая этот файл тоже в консоли. Т. е. пара кликов мышью и новый тест запущен.

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

Если бы нужно было запустить профилирование, то еще одна строчка, которая запускает SJK, и профилирование готово.

Java Flight Recorder то же самое. Здесь я реализовал через профиль.

JVisual VM то же самое, тоже через профиль.

https://bit.ly/jmeter-bench

https://github.com/polarnik/Apache.JMeter.Benchmark.NG

Все эти примеры можно будет посмотреть в репозитории, который сохранен на GitHub. Там более 20 скриптов ко всем плагинам со всеми настройками. Есть подходы, как скомбинировать это в виде опций jmeter-maven-plugin, как это все передавать. Есть там же и документация.

Что я могу сказать, резюмируя все сказанное?

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

Скрипты. Они дают самый больший boost иногда.
А также настройки JMeter.
Настройки операционной системы дают меньший boost.
А если вы просто хотите сделать вашу работу более итеративной, более шустрой, то используйте связку из этих трех инструментов: Maven, jmeter-maven-plugin, IntelliJ IDEA. И вы будете в единицу времени выдавать больше скриптов, больше правок, будете более спокойны.

Если хотите найти презентацию, то есть отличная группа: https://t.me/qa_load, где примерно 300 специалистов по производительности пишут и помогают друг другу. Заходите, присоединяйтесь, буду рад!

Вопросы

Спасибо за доклад! Может быть, глупый вопрос, возможно, был ответ на одном из первых слайдов. Зачем надо было ускорять работу JMeter? Одна из метрик это throughput, которую он выдает. И у вас было недостаточно throughput, которыми вы нагружаете свои сервисы и поэтому вы искали способ ускорить, нагрузить больше сервис или какая-то причина была?

Спасибо за вопрос! Тут целый комплекс историй, они не на один час. Но в общем и целом так: помогая ребятам в чатиках, просто при личном общении, я слышал, что они жалуются на то, что JMeter тормозит. Они спрашивали: Что делать?. При этом причины были самые разные.

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

Другие причины чисто технические, что как-то не так скомпоновано и нужно изменить подход, изменить опции. С некоторыми причинами я сталкивался сам.

Пока вы запускаете тесты разово, единично и не поставили это на поток, вам особо не нужно заботиться о том, насколько они шустрые и сколько ресурсов потребляют. Но как только вы захотели на каждый build запускать нагрузочный тест, вам захочется, чтобы pool нагрузочных станций был поменьше, чтобы ресурсов он требовал поменьше. И не чтобы JMeter тормозил, а, чтобы тормозила система.

И как можно заметить, в некоторых моментах вы можете получить абсолютно разное время: 1,5 секунды на скачивание, 7 секунд, 5 секунд это же важно. В некоторых моментах хочется минимально-минимальное время. И его можно достичь.

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

Вы говорили про настройки операционной системы, что можно это дело как-то ускорить. Это касалось только Linux?

Да, Linux.

А в Windows есть что-то подобное?

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

Но что известно? Чем характеризуется соединение? Это IP-адрес клиента, IP-адрес сервера и порты. Если мы не можем как-то увеличить диапазон портов, настройки переиспользования, то мы, возможно, сможем увеличить диапазон IP-адресов. Т. е. разделить наш сервер, допустим, на два IP, чтобы мы отправляли запросы не в local host 5555, а в local host и еще куда-то. Тогда наш диапазон увеличится в два раза.

В старом JMeter еще была такая опция, когда мы могли привязать текущий клиент к определенному IP. И мы могли расширять диапазон IP на клиенте. Таким образом не залазить ни в одну настройку, а просто говорить, что тест сейчас запускается с трех-четырех-пяти адресов. В актуальной версии это удалили. Это как-то можно придумать иначе.

Я уже с Windows, перешел на Linux. В некоторых моментах приходится возвращаться к Windows, когда идет тестирование скриптографии, но там не нужны большие интенсивности и какие-то запредельные вещи.

Подробнее..

Категории: Тестирование it-систем , Тестирование веб-сервисов , Нагрузочное тестирование

Перевод Flame-графики огонь из всех движков

12.10.2020 18:16:09 |

Автор: admin

Всем снова привет! Приглашаем на онлайн-встречу с Василием Кудрявцевым (директором департамента обеспечения качества в АО РТЛабс), которая пройдёт в рамках курса Нагрузочное тестирование. И публикуем перевод статьи Michael Hunger software developer and editor ofNeo4j Developer BlogandGRANDstack!

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

К счастью, Брендан Грегг, инженер по производительности в Netflix, придумал flame-графики, гениального вида диаграммы для трассировки стека, которые можно собрать практически из любой системы.

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

Flame-график бенчмарка заполнения непредаллоцированного ArrayList

Flame'ы снизу вверх отражают прогрессию от точки входа программы или потока (main или цикл событий) до листьев выполнения на концах flame'ов.

Вы сразу увидите, если некоторые части программы будут занимать неожиданно большое количество времени. Чем выше на диаграмме вы это видите, тем хуже. А если у вас есть очень широкий flame сверху, то вы точно нашли узкое место, где работа не делегируется куда-либо еще. После устранения проблемы, измерьте время работы еще раз, если проблема с производительностью сохранится, вернитесь к диаграмме, чтобы понять, где осталась проблема.

Для устранения недостатков стандартных профайлеров многие современные инструменты используют внутреннюю функцию JVM (AsyncGetCallTrace), которая позволяет собирать трассировки стека независимо от безопасных точек. Помимо этого, они объединяют измерение JVM-операций с нативным кодом и системных вызовов операционной системы, так что время, проведенное в сети, ввод/вывод или сборка мусора, также может стать частью flame-графа.

Такие инструменты, как Honest Profiler, perf-map-agent, async-profiler или даже IntelliJ IDEA, умеют захватывать информацию и с легкостью делать flame-графики.

В большинстве случаев вы просто скачиваете инструмент, предоставляете PID вашего Java-процесса и говорите инструменту работать в течение определенного периода времени и генерировать интерактивный SVG.

# download and unzip async profiler for your OS from:# https://github.com/jvm-profiling-tools/async-profiler./profiler.sh -d <duration> -f flamegraph.svg -s -o svg <pid> && \open flamegraph.svg  -a "Google Chrome"

SVG, создаваемый этими инструментами, не просто красочный, но и интерактивный. Вы можете увеличивать секции, искать посимвольно и т.д.

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

Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок Скрипты и сценарии нагрузочного тестирования- Performance center (PC) и Vugen!

Подробнее..

Категории: Тестирование it-систем , Java , Блог компании otus. онлайн-образование , Тестирование веб-сервисов , Qa , Нагрузочное тестирование , Qa automation , Load testing , Performance , Profiling , Visualisation , Intellij idea , Flame

Нагрузочное тестирование что в нем интересного и какие навыки нужны?

26.10.2020 16:12:51 |

Автор: admin

Попросили рассказать о перспективах и задачах в сфере тестирования производительности Василия Кудрявцева, директора по качеству АО РТЛабс и руководителя нашего курса Нагрузочное тестирование.

Самая актуальная на сегодня область в QA

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

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

Можно рассчитывать на зарплату на 30-50% выше, чем по другим направлениям тестирования.

Каждый проект в нагрузочном тестировании уникален

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

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

Василий Кудрявцев

QA Load самая разнообразная область, где специалисту надо не только заниматься кодом, но и всесторонне развиваться.

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

Как стать нагрузочным тестировщиком?

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

Курс QA Load мы собрали из крупиц материалов, объединив свой опыт решения задач для различных компаний. 70% программы содержит практику и именно это отличает ее от остальных учебных проектов. У нас нет поверхностных тем, каждая изучается вглубь, с разбором кейсов и возможностью попробовать инструмент, потренировать навык.

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

Во втором модуле вы изучите 4 основных инструмента нагрузочного тестирования: Performance center, Jmeter, Gatling, k6.io. Хотя их на рынке несколько больше, мы после опросов выделили используемые повсеместно и этого набора должно хватить, чтобы решить 90% нагрузки. Чтобы эти инструменты сразу можно было встраивать в DevOps-процессы, есть отдельный урок про автоматизацию нагрузочного тестирования с помощью Jenkins, встраивание с помощью CI/CD. Также отдельно расскажем про Grafana и InfluxDB, чтобы соединить эту часть мониторинга с вашими тестами.

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

В течение обучения вас ждет интенсивная работа и 8 домашних заданий: закрепить пройденный материал, попробовать каждый инструмент, написать скрипты, провести тестирование и т.д. Будут задачи на разработку профиля НТ, настройку логирования и проведения регрессионного тестирования для веб-сайта. Для тех, кто хочет получить еще больше навыков и пользы, в заданиях есть пункты со звездочкой. Тренироваться вы будете на реальных системах, серверах, сайтах. Стенды для отработки предоставит партнер курса AdvancedHosting.

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

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

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

Василий Кудрявцев

Кому нужны навыки нагрузочного тестирования?

Наш курс рассчитан на уже разбирающихся в тестировании специалистов. Чтобы успешно осваивать программу нужно обладать базой программирования на одном из языков в ходе обучения вы столкнетесь с SQL, Java, C, Scala, также предстоит много работы в Linux, поэтому понадобится знать базовые вещи: как подключиться к консоли, найти файл и т.д.

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

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

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

В новом потоке QA Load занятия начнутся 29 октября и будут длиться 4 месяца. Если направление вас заинтересовало, проходите вступительный тест и записывайтесь в группу, пока есть места. Ждем вас и до встречи в OTUS!

Подробнее..

Категории: Тестирование it-систем , Тестирование мобильных приложений , Карьера в it-индустрии , Блог компании otus. онлайн-образование , Тестирование веб-сервисов , Нагрузочное тестирование , Тестирование производительности

Перевод Запускаем Gatling из Gradle Полное руководство для начинающих

02.04.2021 14:12:19 |

Автор: admin

Привет, Хабр. Для будущих учащихся на курсе Нагрузочное тестирование подготовили перевод статьи.

Также приглашаем посетить открытый вебинар на тему Начало работы с Jmeter: запись скрипта, параметризация, отладка.

Хотите узнать, как использовать Gatling через Gradle? Тогда вы по адресу. В последнее время я достаточно часто использую инструмент стресс-тестирования Gatling. Он стал одним из моих излюбленных инструментов для тестирования производительности. На сайте Gatling есть неплохая документация по началу работы. Но она подразумевает загрузку zip-файла, а затем запуск BAT или SH скрипта для запуска Gatling. А затем вам нужно выбрать из списка тест, который вы хотите запустить.

Так что да, было бы намного приятнее делать все вышеперечисленное через Gradle. И естественно, намного удобнее. В частности, если вы хотите запускать Gatling-тесты как часть вашего Continuous Integration. Одним из наибольших преимуществ этого подхода является то, что Gatling может зафейлить вашу CI-сборку, если будет нарушен определенный порог производительности (например, слишком много ошибок или слишком большое среднее время отклика и т. д.).

Если вы хотите запускать Gatling через Gradle, вам понадобится плагин Gatling Gradle.

Это руководство проведет вас через настройку плагина Gradle для нового Gatling-проекта.

Чтобы сделать это руководство еще более удобным для новичков, мы будем производить настройку в IDE (Intellij). После завершения работы по настройке вы можете переключиться на запуск исключительно через командную строку, если вам угодно.

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

Предварительные требования

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

1. Java 8 JDK

Вероятно, он у вас уже есть, но если нет, то здесь можно найти подробное руководство по установке JDK для всех типов ОС.

Я настоятельно рекомендую вам использовать Java 8 с Gatling, так как он наиболее с ним совместим.

2. Intellij

В этом руководстве я буду использовать Intellij, вы можете скачать последнюю версию Intellij здесь.

И это все, что вам нужно! Gatling Gradle плагин берет на себя установку Scala, и если же вы запускаетесь через Gradle Wrapper, то нет никакой необходимости даже загружать или устанавливать Gradle на вашей системе.

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

Руководство по запуску Gatling из Gradle

Создать Gradle-проект для Scala в Intellij, как я выяснил с годами, удручающе сложно.

Лучший способ начать создать образец проекта (sample project).

Выполните следующую команду в терминале или командной строке, чтобы создать образец проекта с плагином Gatling Gradle:

curl -sL https://raw.githubusercontent.com/lkishalmi/gradle-gatling-plugin/master/bootstrap.sh | \    bash -s ~/sample-gradle-gatling && \    cd ~/sample-gradle-gatling && ./gradlew gatlingRun

2. Откройте начальную страницу IntelliJ и выберите Import Project.

Import Project to IntelliJ

3. Выберите файл build.gradle из репозитория, который вы загрузили на шаге 1, и нажмите Open.

Select build.gradle file

4. Откройте файл SampleSimulation.

Open Sample Simluation

5. Вы можете увидеть всплывающее окно, подобное ниже. Выберите Setup Scala SDK.

Setup Scala SDK

6. Выберите SDK для Scala. Если его нет в списке, вам вместо этого может потребоваться кликнуть Configure и сначала загрузить бинарники Scala.

Choose Scala SDK

7. На этом этапе уже все должно быть настроено. Чтобы запустить Gatling-тест из Gradle, введите:

./gradlew gatlingRun

Или, чтобы запустить конкретный тест:

./gradlew gatlingRun-SampleSimulation

Для получения дополнительных сведений об использовании и настройке плагина с официальной документацией Gatling Gradle Plugin.

Узнать подробнее о курсе Нагрузочное тестирование.

Смотреть открытый вебинар на тему Начало работы с Jmeter: запись скрипта, параметризация, отладка.

Подробнее..

Категории: Тестирование it-систем , Gradle , Нагрузочное тестирование , Gatling , Jmeter , Java jdk , Блог компании otus

Перевод Нагрузочное тестирование на Gatling Полное руководство. Часть 1

16.04.2021 20:09:46 |

Автор: admin

Эта статья представляет собой полное, подробное и исчерпывающее руководство по эффективному использованию Gatling для нагрузочного тестирования. Вы также можете ознакомиться с моими видеоуроками по Gatling на YouTube, где я более подробно раскрываю эту тему.

Краткий обзор руководства

Если вам нужно провести нагрузочное тестирование вашего сервера HTTP-приложений, то Gatling - идеальный инструмент для этой задачи! Эта серия статей будет представлять собой подробное практическое руководство по нагрузочному тестировании на Gatling. К концу этого руководства у вас появится хорошее представление об использовании Gatling, которое вы сможете применить в ваших последующих проектах по нагрузочному тестированию.

Первый раз слышите о Gatling? Тогда для начала уделите внимание моей вводной статье о Gatling. Но если в двух словах:

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

Простой и выразительный DSL, который предлагает Gatling, упрощает написание скриптов нагрузочного тестирования.

Он не содержит графического интерфейса (например, как JMeter), хотя поставляется с графическим интерфейсом для облегчения записи скриптов.

Он может обрабатывать огромный объем трафика на одном компьютере, устраняя необходимость в сложной распределенной инфраструктуре тестирования.

Проверку кода с помощью Gatling можно встроить в систему контроля версий и легко использовать в связке с инструментами непрерывной интеграции для запуска нагрузочных тестов и тестов производительности как части вашей CI-сборки.

Что такое тестирование производительности?

Прежде чем мы начнем, давайте вкратце разберемся, что такое тестирование производительности (performance testing).

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

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

Существует несколько различных типов тестирования производительности, такие как:

Нагрузочное тестирование (Load Testing) - тестирование системы на заранее определенном объеме пользователей и трафике (пропускной способности);

Стресс-тестирование (Stress Testing) - тестирование системы под постоянно увеличивающейся нагрузкой, чтобы найти точку останова (breakpoint).

Тестирование стабильности (Soak Testing) - тестирование со стабильным уровнем трафика в системе на более длительном периоде времени для выявления узких мест.

Gatling подходит для всех этих подвидов тестирования производительности.

Вот некоторые из метрик, которые вы можете собрать во время тестирования производительности:

Время отклика транзакции (Transaction Response Times) - сколько времени требуется серверу, чтобы ответить на запрос.

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

Ошибки (Errors) - сообщения об ошибках, которые начинают появляться в определенные моменты нагрузочного теста (например, тайм-ауты).

Это исчерпывающее учебное руководство по нагрузочному тестированию на Gatling, разделенное на несколько разделов. Если вы новичок в нагрузочном тестировании на Gatling, я бы рекомендовал вам ознакомиться с каждый из разделов по порядку.

Исходный код

Вы можете найти весь исходный код из этого руководства в моем репозитории на Github.

1. Установка Gatling

Прежде чем начать что-либо делать, убедитесь, что у вас установлен JDK8 (или более новый). Если вам нужна помощь с этим, ознакомьтесь с этим руководством по установке JDK.

Самый простой способ установить Gatling - загрузить версию Gatling с открытым исходным кодом с сайта Gatling.io. Кликните Download Now, и начнется загрузка ZIP-архива:

Download Gatling

Разархивируйте архив в любое место на вашем компьютере. Откройте полученную папку и перейдите в каталог bin. Оттуда запустите:

gatling.bat - если вы используете Windows

gatling.sh - если вы работаете на Mac или Unix

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

Choose Gatling Simulation to run

Введите 0, чтобы выбрать computerdatabase.BasicSimulation. Вам будет предложено ввести описание запуска (run description), но это необязательно, и его можно оставить пустым.

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

2. Gatling Recorder

Можно, конечно, запускать скрипты, поставляемые с Gatling, но, несомненно, вы захотите разработать скрипты под ваше собственное приложение.

Как только вы овладеете Gatling (к концу этого руководства!), вы сможете писать скрипты с нуля в своей IDE или даже просто в текстовом редакторе.

Но прежде чем заняться этим, для начала вам будет проще использовать встроенный Gatling Recorder для записи вашего пользовательского пути (user journey).

2.1 Создание HAR-файла

Самый удобный способ использования Gatling Recorder, как мне кажется, предполагает генерацию HAR-файла (Http-архива) вашего пользовательского пути в Google Chrome.

Создание этих файлов и их импорт в Gatling Recorder позволяет обойти проблемы с записью на HTTPS.

Чтобы создать HAR-файл, выполните следующие действия:

Откройте тестовый сайт Gatling с базой данных компьютеров - это сайт, с которого мы будем записывать пользовательский путь.
Откройте Chrome Developer Tools и перейдите на вкладку Network.
Кликните Clear, чтобы удалить все предыдущие сетевые вызовы, а затем убедитесь, что красная кнопка записи включена.
Полистайте сайт, чтобы сгенерировать свой пользовательский путь - например, поищите какой-нибудь компьютер, создайте другой компьютер и т. д. Вы должны увидеть, что внутри вкладки Network начинают появляться новые записи.
Кликните правой кнопкой мыши в любом месте вкладки Network и выберите Save all as HAR with content. Сохраните этот файл где-нибудь на вашем компьютере.

Теперь перейдите в свою папку bin Gatling (в которой вы впервые запустили Gatling в предыдущем разделе) и запустите файл recorder.sh в Mac/Unix или recorder.bat в Windows. Загрузится Gatling Recorder.
Измените Recorder Mode в правом верхнем углу на HAR Converter.
В разделе HAR File перейдите к местоположению HAR-файла, созданного на шаге 5.
Назовите свой скрипт, изменив Class Name на, например, MyComputerTest.
Все остальное оставьте как было по умолчанию и кликните Start!
Если все сработает так, как должно, вы увидите сообщение, что все прошло успешно.

Gatling Recorder screenshot

Чтобы запустить скрипт, вернитесь в папку bin Gatling и снова запустите gatling.sh или gatling.bat. После того, как Gatling загрузится, вы сможете выбрать только что созданный скрипт.

Если вы хотите посмотреть на только что созданный скрипт, вы можете найти его в папке user-files/simulations в вашем каталоге Gatling. Откройте скрипт MyComputerTest, который вы только что записали, в текстовом редакторе. Он должен выглядеть как-то так:

import scala.concurrent.duration._import io.gatling.core.Predef._import io.gatling.http.Predef._import io.gatling.jdbc.Predef._class MyComputerTest extends Simulation {val httpProtocol = http.baseUrl("http://computer-database.gatling.io").inferHtmlResources().userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36")val headers_0 = Map("Accept" -> "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9","Accept-Encoding" -> "gzip, deflate","Accept-Language" -> "en-GB,en-US;q=0.9,en;q=0.8","Upgrade-Insecure-Requests" -> "1")val scn = scenario("MyComputerTest").exec(http("request_0").get("/computers").headers(headers_0)).pause(9).exec(http("request_1").get("/computers?f=amstrad").headers(headers_0)).pause(4).exec(http("request_2").get("/assets/stylesheets/bootstrap.min.css").resources(http("request_3").get("/assets/stylesheets/main.css")))setUp(scn.inject(atOnceUsers(1))).protocols(httpProtocol)}

Это ваш скрипт Gatling. Если весь этот код кажется вам чересчур непривычным - не волнуйтесь, мы расскажем обо всем, что вам нужно знать, в последующих разделах руководства.

3. Настройка проекта Gatling

Итак, теперь, когда вы получили представление о том, как выглядит скрипт Gatling (и как с ним запустить нагрузочный тест), давайте приступим к настройке среды для создания наших скриптов. Первое, что нам нужно выбрать, это IDE:

3.1 Выберите IDE для создания скриптов нагрузочного тестирования на Gatling

Хотя вы вполне можете создавать скрипты Gatling в любом текстовом редакторе, гораздо проще (и эффективнее) делать это в IDE. В конце концов, мы будем писать код Scala. Scala работает поверх JVM, поэтому любая IDE, поддерживающая JVM, должна нам подойти.

У вас есть несколько вариантов:

Вы можете использовать Eclipse, очень популярную Java IDE. В последнее время я почти не использовал Eclipse в работе, поэтому лучше ознакомьтесь с этой статьей как настроить и запустить тесты Gatling на Eclipse, если вы хотите пойти по этому пути.

Другой вариант, который (недавно) стал доступен, - это Visual Studio Code или сокращенно VS Code. Эта IDE последние несколько лет развивалась с головокружительной скоростью и стала популярной среди разработчиков множества различных технологических стеков. Ознакомьтесь с другой моей статьей Создаем Gatling скрипты с помощью VS Code для получения указаний по настройке.

Мой личный выбор, который я и буду показывать в этом руководстве, - это IntelliJ IDEA. Бесплатная версия достаточно хороша и поставляется со встроенной поддержкой Scala. Она идеально подходит для разработки скриптов Gatling.

Теперь, когда мы выбрали нашу IDE, нам понадобится система сборки, которая будет сочетаться с ней:

3.2 Выберите систему сборки для Gatling

Конечно, вы можете использовать Gatling без системы сборки и просто запускать его из первичных zip-файлов (как мы делали в первом разделе). Но есть вероятность, что вскоре вы все-таки захотите использовать систему сборки в своем проекте нагрузочного тестирования Gatling. Это упростит обслуживание в системе контроля версий. Опять же, у вас есть несколько вариантов на выбор:

Вы можете использовать Gradle, чрезвычайно популярную систему сборки. Как ни странно, Gatling не предоставляет официального плагина для Gradle, поэтому я рекомендую плагин Gradle для Gatling от lkishalmi. Ознакомьтесь с моей статьей Запускаем Gatling из Gradle Полное руководство для начинающих, если вам нужна помощь в настройке.

Еще один хороший вариант - Scala Build Tool, или сокращенно SBT. Gatling предоставляет официальный плагин SBT. Обязательно ознакомьтесь с демо проектом плагина SBT для Gatling, чтобы разобраться, как он настраивается.

Третий вариант, который я снова предпочитаю и который буду использовать в этом руководстве, - это Maven. Если вы работали с Java, вероятно, в какой-то момент вы уже использовали Maven. Существует официальный плагин Maven для Gatling, и демо проект плагина Maven для Gatling, с которым вы можете ознакомиться.

Я расскажу о настройке нового проекта в IntelliJ Idea с Maven в оставшейся части этого раздела.

3.3 Создание проекта Gatling из архетипа Maven

Откройте терминал или командную строку и введите:

mvn archetype:generate

В конце, вы увидите этот запрос:

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains):

Введите gatling.

Затем вы должны увидеть:

1: remote -> io.gatling.highcharts:gatling-highcharts-maven-archetype (gatling-highcharts-maven-archetype)

Просто введите 1 для выбора архетипа Gatling. На следующем экране выберите последнюю версию:

Choose Gatling Version

Я ввел 35, чтобы выбрать версию 3.3.1 для этого туториала.

Для groupId введите com.gatlingTest.

Для artifactId введите myGatlingTest.

Для version просто нажмите ENTER, чтобы принять 1.0-SNAPSHOT.

Для package нажмите ENTER еще раз, чтобы принять в качестве имени пакета com.gatlingTest.

В конце введите Y, чтобы подтвердить все настройки, и Maven создаст для вас новый проект.

Следующее, что нужно сделать, - это импортировать этот проект в вашу IDE. Я импортирую проект в IntelliJ.

На стартовой странице IntelliJ выберите Import Project.

Import IntelliJ Gatling project

Перейдите в папку проекта, которую вы только что создали, и выберите файл pom.xml. Кликните open, и Intellij начнет импортировать проект в IDE за вас.

После того, как импорт проекта будет завершен, откройте панель Project Directory слева и раскройте папку src>test>scala. Дважды кликните по классу Engine.scala. Вы можете увидеть сообщение No Scala SDK in module вверху экрана. Если это так, нажмите Setup Scala SDK:

Import Scala SDK in IntelliJ

Проверьте, какие версии Scala у вас есть:

Scala versions in IntelliJ

Если у вас нет версии, указанной здесь, кликните Create, выберите версию 2.12 и кликните кнопку download:

ПРИМЕЧАНИЕ: Я НАСТОЯТЕЛЬНО рекомендую использовать версию Scala 2.12 с IntelliJ - 2.13, похоже, не очень хорошо работает с Gatling

Download Scala in Intelli

В качестве альтернативы, если у вас возникли проблемы с загрузкой бинарников Scala через IntelliJ, вы можете вместо этого загрузить бинарники Scala непосредственно со Scala-lang. Кликните Download the Scala binaries, как показано на этом скриншоте:

Download Scala binaries from Scala-lang

Сохраните бинарники где-нибудь на жестком диске и распакуйте ZIP-архив. Вернувшись в IntelliJ, снова кликните Setup Scala SDK, и на этот раз кликните Configure. Нажмите кнопку Add в левом нижнем углу:

Add the Scala binaries to IntelliJ

Перейдите в папку, которую вы только что загрузили и распаковали, и выберите папку lib:

Select the Lib folder to import Scala Binaries

Теперь в диалоге Add Scala Support вы сможете выбрать библиотеку Scala, которую вы загрузили:

Add Scala Support

На этом моменте, вам также может потребоваться пометить папку scala как source root в IntelliJ. Для этого кликните правой кнопкой мыши по папке scala и выберите Mark Directory As -> Test Sources Root:

Mark Test Sources as Root in IntelliJ

На всякий случай также отметьте всю папку src как source root:

Mark Sources Root

Наконец, кликните правой кнопкой мыши объект Engine и выберите Run:

Run the Engine Object in IntelliJ

Вы должны увидеть сообщение типа There is no simulation script. Please check that your scripts are in user-files/simulations. Так и должно быть, далее мы приступим к настройке наших скриптов нагрузочных тестов Gatling.

3.4 Добавление базового скрипта Gatling

Чтобы протестировать нашу новую среду разработки, давайте добавим базовый скрипт Gatling. Этот скрипт запустит тест на базе данных компьютеров Gatling.

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

Кликните правой кнопкой мыши папку scala и выберите New > Scala Package - назовите пакет computerdatabase. Кликните эту папку правой кнопкой мыши и выберите New > Scala Class - назовите этот класс BasicSimulation. Скопируйте весь приведенный ниже код в новый класс:

package computerdatabaseimport io.gatling.core.Predef._import io.gatling.http.Predef._import scala.concurrent.duration._class BasicSimulation extends Simulation {  val httpProtocol = http    .baseUrl("http://computer-database.gatling.io") // Здесь находится корень для всех относительных URL    .acceptHeader(      "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"    ) // Вот общие заголовки    .acceptEncodingHeader("gzip, deflate")    .acceptLanguageHeader("en-US,en;q=0.5")    .userAgentHeader(      "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0"    )  val scn =    scenario("Scenario Name") // Сценарий представляет собой цепь запросов и пауз       .exec(        http("request_1")          .get("/")      )      .pause(7) // Обратите внимание, что Gatling записал паузы в реальном времени  setUp(scn.inject(atOnceUsers(1)).protocols(httpProtocol))}

Теперь давайте запустим скрипт. Кликните правой кнопкой мыши объект Engine и выберите Run Engine. Gatling загрузится, и вы должны увидеть сообщение computerdatabase.BasicSimulation is the only simulation, executing it. Нажмите Enter, и скрипт выполнится.

Мы также можем запустить наш Gatling тест напрямую через Maven из командной строки. Для этого откройте терминал в каталоге вашего проекта и введите mvn gatling:test. Эта команда выполнит Gatling тест с помощью плагина Maven для Gatling.

Наша среда разработки Gatling готова к работе! Теперь нам нужно приложение, которое мы будем тестировать. Мы могли бы использовать базу данных компьютеров Gatling, но вместо этого я разработал API-приложение специально для этого туториала - базу данных игр!

В преддверии старта курса "Нагрузочное тестирование" приглашаем всех желающих записаться на бесплатный демо-урок в рамках которого рассмотрим интерфейс LoadRunner Virtual User Generator, запишем скрипт тестирования web-сайта, проведём его отладку и параметризацию. В результате вы научитесь создавать скрипты нагрузочного тестирования web-сайтов.

ЗАПИСАТЬСЯ НА ДЕМО-УРОК

Подробнее..

Категории: Тестирование it-систем , Gradle , Тестирование веб-сервисов , Qa , Нагрузочное тестирование , Gatling , Блог компании otus

	Русский
	English

Нагрузочное тестирование

Шаг 1. Установка

Шаг 2. Создаем config

Target url, environment

Фазы тестирования

Плагины

Авторизация

Шаг 3. Первый тест

Шаг 4. Запуск тестов

Создание html отчета

Сравнение с K6

TSS

Объём Fk

TSE

Заключение

Литература

1. Что такое Cisco TRex

2. Как получить и попробовать TRex

3. Автоматизация разработки и тестирования с помощью TRex

Заключение

Основные метрики

Индикаторы

Таблица с временем отклика

График Virtual Users

График Response Time

Вариации графика

Распределение Response Time

Latency

Bandwidth

График Request Per Second

TPS

График Errors

HTTP responses status

График Throughput

Возможные модификации

Получение графиков

Матричное описание метрик

Откуда берётся сложность

Симуляция пользователей. Действительно ли она нужна?

Написание тестов сложная задача. Как и их поддержка.

Может быть, не подвергать всё нагрузочному тестированию?

На правах рекламы

Web-система. Ver 1.0

У нас новомодная технология и наша система высокопроизводительная... ?!

Провал

Web-система. Ver. 2.0

Мы все переделали. Уж теперь точно полетит?!

Результат

Заключение

Лучшие советы для успешного тестирования производительности

1. Запускайте нагрузочные тесты из производственной среды

2. Масштабируйте свои тесты от маленького к большому и далее к огромному

3. Запланируйте тесты

4. Мониторинг внутренних результатов нагрузочного теста

5. Включите отслеживание производительности конечного пользователя в бэкэнд-тестирование

6. Настройте резервные серверы и локации

7. Проверьте ваши сторонние интеграции

8. Внедрить мониторинг API

Вячеслав Смирнов Ускоряем Apache JMeter

Самая актуальная на сегодня область в QA

Каждый проект в нагрузочном тестировании уникален

Как стать нагрузочным тестировщиком?

Кому нужны навыки нагрузочного тестирования?

Предварительные требования

1. Java 8 JDK

2. Intellij

Руководство по запуску Gatling из Gradle

Краткий обзор руководства

Что такое тестирование производительности?

Исходный код

1. Установка Gatling

2. Gatling Recorder

2.1 Создание HAR-файла

3. Настройка проекта Gatling

3.1 Выберите IDE для создания скриптов нагрузочного тестирования на Gatling

3.2 Выберите систему сборки для Gatling

3.3 Создание проекта Gatling из архетипа Maven

3.4 Добавление базового скрипта Gatling

Категории

Последние комментарии