Тестирование очень больших нагрузок на приложение: подводные камни и полезные инструменты (часть II)

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

Начало истории — в этом посте.

Настройка виртуальных машин

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

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

По умолчанию этот предел выставлен на уровне около 10 000. Если значение не изменить, ваша «виртуалка» просто не сможет генерировать больше виртуальных пользователей.

Информация о максимальном числе процессов хранится в файле /proc/sys/kernel/pid_max, который легко можно просмотреть, используя команду:

cat /proc/sys/kernel/pid_max

Если значение в файле вас не устраивает — меняйте его и перезапускайте тест.

Анализ результатов

«‎‎Вишенка» на торте — результаты. Когда тесты уже «прогнаны‎»‎ и дело вроде бы осталось за малым, гигабайтные файлы логов говорят: «Не тут-то было!‎». Огромные нагрузки генерируют такие же огромные файлы логов. Отсюда проблема: что с ними делать? Как прочитать полученный результат?

Excel не так хорош, как хотелось бы. К сожалению, «‎‎из коробки» Excel вообще не может отобразить таблицу больше 1 млн строк, так что если ваш тест сгенерировал результат в формате CSV длиной больше, чем 1 млн строк, то Excel его целиком обработать не сможет.

Как вариант: сгенерировать pivot tables на основе файла с результатами, которые обрабатываются относительно быстро. Не рекомендую пытаться что-то высчитывать с помощью обычных формул, так как они работают очень медленно по сравнению со сводными таблицами.

Есть специальные инструменты для работы с большими текстовыми файлами. Оказалось, что текстовый файл размером в несколько десятков гигабайт не может открыть ни обычный «Блокнот», ни какой-либо другой текстовый редактор, который был у меня установлен.

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

Стандартный HTML-отчет JMeter может работать с большими массивами данных. У JMeter есть встроенная возможность строить HTML-отчеты с графиками и относительно красивым интерфейсом. Удивительно, но как раз эти отчеты генерируются из любого размера файла логов. Главное ограничение — доступная оперативная память.

Если генерация отчета не была включена через параметр generateReports в pom.xml-файле, то его можно все равно сгенерировать вручную двумя способами:

1. Через интерфейс JMeter. Процесс описан тут.
2. Путем выполнения консольной команды:
   

   jmeter -n -t <test JMX file> -l <test log file> -e -o <Path to output folder>

Выводы

• При планировании performance-тестирования надо всегда заранее выяснять требования и находить подходящие инструменты.
• Старайтесь «на берегу» продумывать всю работу, которую нужно будет выполнять впоследствии.
• Особенно хорошо, если получается заранее сделать «инвестигейт» и обкатку выбранного инструмента.