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

Перед обновлением или переездом на новое железо всегда звучит вопрос: «а выдержит?». Ответ обычно даёт первый понедельник после запуска. Нагрузочный тест переносит этот понедельник на неделю раньше, в тестовый контур. Разбираем, как подступиться к нему на JMeter, если раньше этого не делали, и почему сценарии, написанные под одну версию RX, перестают работать на следующей.

Симптом

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

Почему так

Нагрузочный тест полезен, только если похож на реальную работу. Три частые причины, по которым он не похож:

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

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

Сценарий привязан к версии. Запросы веб-клиента к серверу это внутреннее устройство системы, а не публичный интерфейс. С новой версией меняются адреса, состав параметров, порядок вызовов. Записанный сценарий ломается, и чаще тихо: запросы уходят, ответы приходят, но это ответы об ошибке.

С чего начать: профиль

До JMeter нужно ответить на два вопроса: какие действия пользователи делают и сколько раз в час в пиковое время.

Ответ лежит в журналах. RX пишет операции пользователей и их длительность в поле span (по документации вендора это сохранение карточки, формирование отчёта, открытие документа и подобное), журналы веб-клиента лежат в подпапке remote. Если журналы собраны в одно хранилище (как это сделать, разобрано в статье про Vector), профиль получается одним запросом: число операций по типам за самый нагруженный час. Если не собраны, хватит выборки файлов за один рабочий день.

Из профиля берут пять-десять самых частых действий и два-три самых тяжёлых. Это и будут сценарии теста. Число одновременных пользователей берут не из лицензии, а из журналов: сколько разных учётных записей было активно в пиковый час.

Запись сценария

JMeter умеет записывать запросы браузера: в план добавляется HTTP(S) Test Script Recorder, браузер настраивается работать через него как через прокси, и вы проходите действие руками. Для HTTPS JMeter генерирует свой корневой сертификат, его нужно добавить в доверенные в браузере.

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

Корреляция

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

Корреляция это замена таких значений переменными, которые сценарий достаёт из предыдущих ответов:

  • JSON Extractor достаёт значение из ответа в формате JSON, например идентификатор созданной задачи;
  • Regular Expression Extractor для всего остального;
  • HTTP Cookie Manager в плане обязателен: он хранит куки сессии каждого виртуального пользователя.

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

Проверки ответов

На каждый запрос, который что-то меняет, ставится проверка. Response Assertion на текст или JSON Assertion на поле ответа. Проверка кода 200 недостаточна, нужно проверить, что в ответе есть ожидаемое, а ошибки нет.

Как писать свой сэмплер

Когда записанного мало, например нужна логика «взять случайный документ из папки и открыть его», пишут JSR223 Sampler или JSR223 PreProcessor на Groovy. Groovy в JMeter компилируется и работает быстро, в отличие от устаревшего BeanShell.

// JSR223 PreProcessor: случайный документ из списка, полученного предыдущим запросом
def ids = vars.get("doc_ids")?.split(",")
if (!ids) {
    log.warn("Список документов пуст")
    return
}
vars.put("doc_id", ids[new Random().nextInt(ids.length)])

Данные для потоков (учётные записи, номера документов) подставляются из файла через CSV Data Set Config: у каждого виртуального пользователя своя учётка, иначе тест меряет блокировки одного пользователя.

Запуск

Интерфейс JMeter нужен для отладки. Сам тест запускают без него, иначе JMeter тормозит сам и врёт в замерах:

jmeter -n -t plan.jmx -l results.jtl -e -o report/

В каталоге report будет HTML-отчёт: время ответа по перцентилям, ошибки, пропускная способность.

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

При новой версии RX

  1. Пройти каждый сценарий одним потоком с включённым View Results Tree и проверить, что все проверки ответов зелёные. Красные показывают, какие запросы изменились.
  2. Изменившиеся шаги перезаписать заново. Ручная правка записанных запросов дольше и чаще ошибается.
  3. Держать запросы сгруппированными по действиям (Transaction Controller на каждое действие пользователя): при обновлении перезаписывается одно действие, а не весь сценарий.
  4. Сравнивать результаты с прошлой версией на одном и том же контуре и профиле. Абсолютные числа мало что говорят, разница между версиями говорит много.

Чего не делать

  • Не нагружать продуктивный контур. Только тестовый, поднятый из бэкапа прода.
  • Не мерить без проверок ответов. Быстрый тест с ошибками внутри хуже, чем никакого.
  • Не запускать нагрузку из интерфейса JMeter.
  • Не давать всем потокам одну учётную запись.
  • Не делать выводы по среднему времени. Жалобы пользователей соответствуют 95-му и 99-му перцентилю, почему так, разобрано в статье про перцентили.