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

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

Нагрузочное тестирование используется для оценки поведения Global ERP под рабочей, пиковой и длительной нагрузкой. Основной инструмент генерации нагрузки — JMeter.

Нагрузочное тестирование может охватывать:

  • серверы приложений Global ERP;

  • PostgreSQL;

  • файловое хранилище;

  • REST API и внешние интерфейсы;

  • фоновые задания и планировщики;

  • пользовательские операции в HTML5-клиенте;

  • операции загрузки, скачивания и обработки файлов.

Для каждого прогона фиксируются:

  • цель теста;

  • тестируемый контур;

  • версия приложения;

  • версия БД;

  • состав инфраструктуры;

  • объем тестовых данных;

  • профиль нагрузки;

  • параметры JMeter-сценария;

  • время начала и окончания теста;

  • ссылки на отчет JMeter, мониторинг и логи.

Подготовка тестирования#

Готовность стенда#

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

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

Инструмент нагрузочного тестирования#

Для генерации нагрузки используется JMeter.

Через JMeter можно запускать:

  • HTTP/API-сценарии;

  • REST-вызовы;

  • пользовательские сценарии.

Тестовые данные#

Тестовые данные должны соответствовать цели нагрузочного теста и ожидаемому объему промышленной эксплуатации.

В описании теста указываются:

  • количество пользователей;

  • количество ролей и профилей;

  • объем справочников;

  • количество документов и бизнес-объектов;

  • объем файловых вложений;

  • объем БД;

  • наличие исторических данных;

  • наличие данных для отчетов и печатных форм.

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

Сценарии нагрузки#

Сценарий нагрузки должен описывать конкретные операции, которые выполняет JMeter.

В сценарий могут входить:

  • авторизация пользователя;

  • открытие выборки;

  • применение фильтра;

  • открытие карточки объекта;

  • создание и сохранение объекта;

  • выполнение операции;

  • формирование печатной формы;

  • загрузка или скачивание файла;

  • вызов REST API.

Пример пользовательского сценария:

  1. Выполнить авторизацию.

  2. Открыть выборку документов.

  3. Применить фильтр.

  4. Открыть карточку документа.

  5. Изменить атрибут.

  6. Сохранить документ.

  7. Сформировать печатную форму.

  8. Проверить HTTP-статус и время ответа.

Профиль нагрузки#

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

В профиле указываются:

  • количество виртуальных пользователей;

  • длительность ramp-up;

  • длительность основной фазы теста;

  • частота выполнения операций;

  • распределение операций между сценариями;

  • допустимый процент ошибок;

  • критерии остановки теста.

Пример профиля:

Группа нагрузки

Операция

Количество пользователей / потоков

Пользователи

Открытие выборок

указать значение

Пользователи

Создание и сохранение документов

указать значение

Пользователи

Формирование отчетов

указать значение

API

REST-вызовы

указать значение

Мониторинг#

Во время теста контролируются:

  • состояние pod’ов серверов приложений;

  • CPU и RAM;

  • JVM heap;

  • GC;

  • активные сессии;

  • состояние PostgreSQL;

  • активные запросы и блокировки в БД;

  • долгие SQL-запросы;

  • HTTP-статусы ответов;

  • состояние фоновых заданий;

  • состояние файлового хранилища;

  • состояние сервера JMeter.

Для анализа PostgreSQL можно использовать SQL-запросы из раздела Основные SQL-запросы для анализа.

Создание и настройка#

Настройка нагрузочного теста включает:

  1. Подготовку тестового стенда.

  2. Проверку готовности стенда по админской инструкции.

  3. Подготовку тестовых данных.

  4. Подготовку JMeter-сценария.

  5. Настройку Thread Group.

  6. Настройку HTTP-запросов или REST-вызовов.

  7. Настройку авторизации.

  8. Настройку профиля нагрузки.

  9. Настройку Listener’ов.

  10. Подготовку места хранения логов и отчета.

В JMeter-сценарии указываются:

  • адрес тестового стенда;

  • база данных или контур, если они передаются в заголовках или URL;

  • учетные данные или токен тестового пользователя;

  • путь REST API;

  • тело запроса;

  • количество потоков;

  • ramp-up;

  • длительность теста;

  • таймауты;

  • правила проверки HTTP-статусов;

  • параметры сохранения результата.

Запуск тестов#

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

Пилотный запуск#

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

При пилотном запуске проверьте:

  • доступность тестового стенда;

  • корректность URL и параметров JMeter;

  • авторизацию;

  • корректность тестовых данных;

  • отсутствие ошибок в сценарии;

  • сбор метрик и логов;

  • состояние сервера JMeter.

Требования к проверке сервера JMeter описаны в разделе Проверка сервера JMeter.

Если пилотный запуск выявил ошибки, основной прогон не выполняется до их устранения.

Основной запуск#

Основной запуск выполняется после успешного пилотного прогона.

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

  • адрес тестового стенда;

  • база данных или контур, если они передаются в URL или заголовках запроса;

  • учетные данные или токен тестового пользователя;

  • путь REST API или URL пользовательского сценария;

  • тело запроса, если сценарий выполняет POST- или PUT-запросы;

  • количество потоков в Thread Group;

  • ramp-up и длительность теста;

  • таймауты;

  • правила проверки HTTP-статусов;

  • Listener’ы для анализа результата.

Во время запуска фиксируются:

  • время начала и окончания теста;

  • версия приложения;

  • параметры стенда;

  • параметры JMeter;

  • профиль нагрузки;

  • количество виртуальных пользователей;

  • длительность теста;

  • ссылки на Grafana, Loki, Pyroscope и отчет JMeter.

После завершения теста проверьте результаты в View Results Tree, Summary Report, Aggregate Report или другом настроенном Listener’е.

Минимальный JMeter-сценарий#

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

Примечание

Если JMeter-сценарий использует WebSocket-соединения, необходимо установить плагин JMeter WebSocket Samplers.

Минимальный сценарий содержит:

  • блок переменных variables;

  • переменные server_name, port, login, UserCount;

  • thread group TestFirst;

  • открытие WebSocket-соединения;

  • авторизацию пользователя;

  • выполнение JEXL-запроса;

  • проверку успешного ответа через Response Assertion;

  • извлечение данных ответа через JSON Extractor;

  • закрытие WebSocket-соединения;

  • отчеты View Results Tree, Summary Report и Aggregate Report.

Перед запуском минимального сценария:

  1. Укажите имя сервера в переменной server_name.

  2. Укажите порт в переменной port.

  3. Укажите пользователя, пароль и базу в переменной login.

  4. Укажите количество потоков в переменной UserCount.

  5. Проверьте JEXL-запрос в шаге выполнения сценария.

  6. Проверьте условие успешного ответа в Response Assertion.

  7. Запустите тестирование через операцию Start на панели инструментов.

  8. Дождитесь завершения теста.

  9. Проверьте результаты в View Results Tree, Summary Report или Aggregate Report.

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

Проверка результата#

После завершения теста анализируются результаты JMeter, метрики Global ERP и состояние инфраструктуры.

В отчете JMeter проверяются:

  • количество запросов;

  • количество успешных и ошибочных запросов;

  • среднее, минимальное и максимальное время ответа;

  • медианное время ответа;

  • 95-й и 99-й перцентили;

  • throughput;

  • error rate.

По Global ERP и инфраструктуре дополнительно анализируются:

  • CPU и RAM pod’ов приложения;

  • JVM heap и GC;

  • активные сессии;

  • HTTP-ошибки;

  • ошибки приложения в логах;

  • активные запросы PostgreSQL;

  • долгие SQL-запросы;

  • блокировки;

  • количество соединений с БД;

  • состояние фоновых заданий;

  • файловое хранилище;

  • состояние сервера JMeter.

Критерии успешности задаются до запуска теста. Например:

  • 95-й перцентиль по основным операциям не превышает согласованное значение;

  • процент ошибок не превышает согласованное значение;

  • в логах приложения нет необработанных ошибок уровня ERROR;

  • в БД нет критичных блокировок;

  • сервер JMeter не является ограничивающим фактором;

  • JVM heap стабилен после прогрева;

  • фоновые задания завершились корректно.

По итогам анализа необходимо определить:

  • выдержала ли система заданный профиль нагрузки;

  • какие операции имеют наибольшее время ответа;

  • какие SQL-запросы дают основную задержку;

  • есть ли блокировки в БД;

  • есть ли рост JVM heap;

  • есть ли длительные GC-паузы;

  • равномерно ли распределена нагрузка между pod’ами;

  • не стал ли JMeter ограничивающим фактором;

  • требуется ли масштабирование или оптимизация.

Особенности нагрузочного тестирования#

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

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

  • Стресс-тестирование — выполняется при нагрузке выше расчетной и помогает определить предел системы и условия деградации.

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

  • Пиковое тестирование — проверяет поведение системы при резком увеличении нагрузки: массовом входе пользователей, одновременном открытии выборки, запуске отчетов или всплеске REST-запросов.

При нагрузочном тестировании чаще всего выявляются следующие узкие места:

  • долгие SQL-запросы;

  • отсутствие или неэффективность индексов;

  • блокировки в БД;

  • нехватка соединений в пуле;

  • нехватка CPU или RAM;

  • частые или длительные GC-паузы;

  • неравномерное распределение нагрузки между pod’ами;

  • медленная работа файлового хранилища;

  • избыточные фоновые задания;

  • ограничения сервера JMeter.

По результатам теста могут выполняться:

  • увеличение количества pod’ов серверов приложений;

  • изменение CPU/RAM limits и requests;

  • настройка JVM;

  • оптимизация SQL-запросов;

  • добавление или изменение индексов;

  • настройка пула соединений с БД;

  • настройка PostgreSQL;

  • изменение частоты фоновых заданий;

  • настройка балансировщика нагрузки.

Изоляция и повторяемость#

Для сравнения результатов каждый запуск должен выполняться при зафиксированных параметрах:

  • версия приложения;

  • параметры инфраструктуры;

  • объем тестовых данных;

  • профиль нагрузки;

  • параметры JMeter;

  • состав фоновых заданий.

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

Перед прогоном по согласованию с администратором БД можно сбросить накопительную статистику PostgreSQL, чтобы анализировать только интервал нагрузочного теста. SQL-запросы для проверки расширений, сброса статистики и анализа pg_stat_statements / pgpro_stats приведены в разделе Основные SQL-запросы для анализа.

Интеграция в массовый запуск или CI/CD#

В CI/CD можно запускать:

  • короткий JMeter-тест на основные API после сборки;

  • smoke-нагрузочный тест;

  • ночной нагрузочный тест;

  • тест перед релизом;

  • сравнение результатов с предыдущей стабильной версией.

Результат CI/CD-запуска анализируется по пороговым значениям метрик. При превышении порогов команда должна получить уведомление.

Типовые проблемы#

При нагрузочном тестировании часто возникают следующие проблемы:

  • тестовая среда отличается от промышленной;

  • JMeter-сервер размещен на узлах приложения, БД или мониторинга;

  • сервер JMeter упирается в CPU, RAM, сеть или диск;

  • сценарии не отражают реальные действия пользователей;

  • объем тестовых данных не соответствует промышленному;

  • не настроен сбор метрик и логов;

  • не зафиксирован профиль нагрузки;

  • не определены критерии успешности;

  • фоновые задания искажают результаты;

  • одиночный запуск используется как основание для окончательных выводов.

Рекомендации#

Рекомендуется:

  • использовать JMeter как единый инструмент генерации нагрузки;

  • выполнять пилотный прогон перед основным тестом;

  • фиксировать параметры каждого запуска;

  • проверять, что JMeter не стал узким местом;

  • хранить отчеты JMeter и ссылки на дашборды мониторинга;

  • отдельно анализировать пользовательскую нагрузку и фоновые задачи;

  • сравнивать результаты между версиями системы;

  • выполнять повторное тестирование после оптимизации;

  • проводить тестирование после крупных изменений в бизнес-логике, SQL-запросах, инфраструктуре или версии платформы.

Ограничения#

Нагрузочное тестирование не заменяет функциональные, интеграционные и UI-тесты.

При интерпретации результатов учитывайте:

  • тестовая среда может отличаться от промышленной;

  • результаты зависят от качества тестовых данных;

  • фоновые задания могут влиять на результаты;

  • одиночный запуск не является достаточным основанием для окончательных выводов.

Содержание