Привет! Мы — команда тестирования производительности в Тинькофф, и мы любим инструмент Gatling. В цикле статей мы расскажем об использовании Gatling и дополнительных инструментов, упрощающих разработку скриптов.Возможно, вы уже читали наши статьи про Gatling: первую и вторую. Они успели устареть, поэтому мы решили вернуться с обновленной информацией.  Вы узнаете, как подготовить шаблонный Gatling-проект из нашего шаблона gatling-template.g8, и познакомитесь с базовыми понятиями в Gatling. А также изучите базовые возможности подключаемой библиотеки gatling-picatinny. Кроме того, статья будет полезна новичкам в нагрузочном тестировании (НТ), которые хотят запустить его на своем проекте, но не знают, с чего начать. Мы познакомим вас с Gatling и расскажем об инфраструктуре и инструментах команды НТ Тинькофф, которые вы сможете использовать. Дисклеймер На момент написания статьи используемые плагины поддерживают версию Gatling не выше 3.7.5. Для получения работающего скрипта в будущем достаточно будет обновить версии плагинов в соответствии с их документацией. Шаблон gatling-g8 — это удобный инструмент, который позволяет быстро создавать SBT-проект, в нашем случае — для Gatling-проекта. Он включает в себя готовую структуру каталогов и файлов для написания скриптов, а также подключенную gatling-picatinny. Это библиотека с полезными функциями, расширяющими Gatling DSL и повышающими производительность. Шаблон g8 мы создаем с использованием инструмента giter8. Разберемся, с чего начать работу с gatling-g8. Создание шаблона проекта. Убедитесь, что в вашей системе установлена sbt версии не ниже 1.6.2. Она понадобится для дальнейшей работы. Затем откройте консоль и выполните команду ([version] — указать актуальную версию): После выполнения команды у вас запросят несколько параметров. Укажите только имя вашего сервиса:  Остальные параметры оставляйте как есть. Теперь у вас есть готовый scala-проект для Gatling.Обзор структуры проекта. Рассмотрим, из чего именно состоит проект. Пойдем по каталогам сверху вниз: project — каталог содержит информацию о зависимостях, плагинах и версии sbt проекта; src — основной каталог. Содержит скрипты и конфигурации;2.1. resources — содержит конфигурацию Gatling, настройки симуляции и логирования;2.2. cases — каталог для запросов симуляции;2.3. scenarios — каталог для сценариев симуляции;2.4. test.scala — конфигурация протокола, который используется для тестирования системы;2.5. Debug.scala, MaxPerformance.scala, Stability.scala — готовые симуляции для отладки, теста на поиск максимальной производительности и теста стабильности соответственно. build.sbt — конфигурация sbt. Как видно из структуры, для создания скриптов необходимо написать запросы в каталоге cases. Далее — сформировать из них сценарии в каталоге scenarios и подключить эти сценарии в симуляции Debug.scala, MaxPerformance.scala или Stability.scala. О них расскажем ниже. А затем — добавить в настройки симуляции нужные переменные. О написании скриптов мы подробнее расскажем в следующих статьях. Запуск проекта. Чтобы запустить проект, используйте Gatling runner. Он позволяет запускать скрипты не через sbt-plugin, а напрямую из IntelliJ IDEA. В некоторых случаях это позволяет улучшить опыт отладки с помощью стандартных возможностей IDE (например, breakpoints). Откройте объект GatlingRunner по пути src/test/scala/ru/tinkoff/load/[projectName]/GatlingRunner.scala и измените класс симуляции, который хотите запустить: Затем нажмите на Run GatlingRunner, если работаете в IDE InteliJ IDEA:  Если выбрали другую IDE, воспользуйтесь SBT для запуска в командной строке: Теперь, когда мы рассказали про использование шаблона, предлагаем разобраться с основными понятиями. Симуляция. В общем виде симуляция в Gatling — это класс Scala, который состоит из различных сценариев и инжекторов (способов моделирования нагрузки) для этих сценариев. Симуляцию можно разделить на следующие части: Конфигурация протокола (в примере — HTTP). Определение запросов. Определение сценария. Вызов основного метода симуляции setUp. В примере ниже мы показываем общий вид симуляции без использования нашего шаблона gatling-template.g8.  Типы симуляций. В нашем шаблоне g8 есть три типа предустановленных способов подачи нагрузки: Debug. Используется для отладки и проверки работоспособности логики самих скриптов. MaxPerformance. Используется для запуска тестов со ступенчато-подаваемой нагрузкой. С его помощью мы определяем точки максимальной производительности. Ниже — график и пример его реализации в Gatling.  На графике можно увидеть ступенчато-подаваемую нагрузку. Выход на очередную ступень нагрузки происходит в течение ramp duration. Сама ступень длится в течении stage duration, интенсивность на ступень рассчитывается по формуле intensity / stage numbers, где stage numbers — это количество ступеней в тесте. Stability. Используется для запуска тестов со стабильно подаваемой нагрузкой с предварительным постепенным разгоном. Такой тест может быть полезен для подтверждения стабильной работы приложения и проведения регрессионных тестов. Ниже — пример теста со стабильно подаваемой нагрузкой и код в Gatling. На графике можно увидеть стабильно подаваемую нагрузку. Выход на стабильную нагрузку происходит в течение ramp duration, стабильная нагрузка длится в течение stage duration с интенсивностью intensity. Feeder. Фидеры в Gatling представляют из себя механизм внедрения тестовых данных   в сценарии. Тестовые данные могут поступать из различных источников, например самый распространенный вариант — это чтение данных из файла. Также можно читать данные из БД и писать собственные фидеры, которые генерируют тестовые данные по некоторой функции. Gatling предлагает несколько стратегий для встроенных фидеров: queue — очередь, используется по умолчанию, читает записи последовательно; random — случайным образом выбирает запись из последовательности; shuffle — перемешивает записи, а затем ведет себя как queue; circular — читает записи последовательно, но при достижении конца последовательности начинает заново. При использовании queue или shuffle убедитесь, что ваш набор данных содержит достаточно записей. Если у фидера заканчивается запись, Gatling принудительно закончит тест.Также фидеры делятся на: файловые — читают данные из заранее подготовленных файлов; JDBC — читает данные из базы данных; Sitemap — читает данные из специального формата XML-файлов; Redis — читает данные из Redis. Custom — читает данные из произвольной функции, поставляется с gatling-picatinny. Пример использования файлового фидера: Пример файла value.csv: Разберем, что происходит в этом коде: Мы пишем http-запрос с некоторым параметром, значение которого мы хотим параметризовать. Для этого мы используем специальную конструкцию #{value}. Создаем файловый фидер. Файл содержит заголовок и значения. Заголовок должен называться так же, как и параметр. Добавляем фидер в сценарий. Теперь вместо #{value} там окажется случайное значение из файла. Убедиться, что значения из фидера попали в запросы, можно запустив отладочный сценарий (Debug.scala). Так мы можем «на лету» создавать разные запросы.Сессия. Это состояние виртуального пользователя. В сессии хранятся данные только для этого пользователя. Передача информации между сессиями по умолчанию невозможна, но можно использовать workaround — например, redis. По сути, это пара «ключ-значение», где ключ — это атрибут сессии, или параметр, а значение — это содержимое этого атрибута. В сессии хранятся как различные переменные, например текущее значение фидера, так и название сценария, id виртуального пользователя и другие параметры.Вы можете читать данные из сессии и добавлять их туда. Вот так можно положить значение в сессию: А так — получить из сессии значение:  Еще можно вывести сессию в консоль. Например, с целью отладки: Вывод в консоли выглядит так: Gatling Picatinny. Это библиотека с множеством полезных функций. Она расширяет Gatling DSL и повышает производительность при написании скриптов. Мы уже писали об этой библиотеке в тексте об арсенале Gatling. Полное описание всех функций с примерами вы можете найти в README. А о новых функциях библиотеки мы расскажем ниже.Какие фидеры появились в PicatinnyHashiCorp Vault. Фидер, способный извлекать секретные данные из HC Vault. Авторизация проходит через approle, при этом используется v1 API. Фидер работает с kv Secret Engine. Он не перебирает ключи, а возвращает полную карту с ключами, найденными при каждом вызове. Параметры фидера: vaultUrl — URL хранилища, например https://vault.ru; secretPath — путь к секретным данным в вашем хранилище. Например, testing/data; roleId — approle логин; secretId — approle пароль; keys — список ключей, которые вы хотите получить из хранилища. Utils. Создает токен JWT с использованием шаблона json и сохраняет его в сессии Gatling. После этого вы можете использовать его для подписи запросов. Пример объемный, его лучше посмотреть в README.Random method. Содержит множество различных методов для генерации рандомных значений.Assertion. Загружает конфигурации assertion из файлов YAML. Пример файла nfr.yml: Пример использования: Transactions. Позволяет оборачивать запросы для замера времени, но учитывает паузы в сценарии. Используется на проектах с JDBC и проектах с транзакционной нагрузкой. В этой статье мы познакомились с нашим шаблоном для создания проектов, рассмотрели базовые возможности Gatling и изучили новые функции нашей библиотеки Picatinny. Мы не упомянули результаты тестирования в Gatling, но о них можно узнать из статьи об анализе результатов нагрузочного тестирования. В следующих статьях мы расскажем, как Gatling и другие инструменты помогают создавать скрипты для различных протоколов, таких как HTTP, gRPC, JDBC, AMQP и Kafka. Основные концепции в Gatling. Подробнее о сессии в Gatling. Подробнее о составлении http запросов в Gatling. Подробнее о фидерах в Gatling.