Вход |  Регистрация

Все Тэги

Нагрузочное тестирование Java-приложений – на что стоит обратить внимание

20.02.2015610 просм.

insert_final_1
Урок №2
Материал предоставлен командой DevOps компании ALG Systems.

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

Сервер приложений

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

AppServerHealth

  • Горячие точки CPU. Отвечают на вопросы –
  1. Сколько процессорных мощностей требуется для заданной нагрузки?
  2. Является ли рост равномерным или есть резкие скачки?
  3. Вызван ли сильный рост недостатками кода и можно ли это поправить?
  4. Требуется ли масштабирование и добавление новых серверов приложений?
  • Рабочие потоки. Отвечают на вопросы –
  1. Насколько корректно при конфигурировании подобрано число выделенных потоков?
  2. Есть ли связь между ждущими потоками и неготовностью сервера их обрабатывать?
  3. Нет ли веб-модулей, которые блокируют потоки?
  • Метрики памяти. Отвечают на вопросы –
  1. Существуют ли повторяющиеся проблемные пики? Утечки памяти?
  2. Справляются ли сборки мусора с нагрузкой, правильно ли сконфигурированы?
  3. Какое влияние сборки мусора оказывают на CPU и количество обрабатываемых транзакций?
  • Распределение нагрузки (в случае кластеров). Отвечают на вопросы –
  1. Сколько транзакций обрабатывается каждым отдельным движком?
  2. Насколько равномерно сбалансирована нагрузка?
  3. Есть ли потребность в дополнительных серверах?

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

Major_GC
Хост

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

host

  • CPU, память, диски, I/O. Отвечают на вопросы –
  1. Есть ли нехватка физических или виртуальных ресурсов?
  2. Нет ли чрезмерной нагрузки на дисковую подсистему? Например, от лог файлов или свопа?
  3. Как ведут себя сетевые интерфейсы, нет ли проблем с этой стороны?
  • Запущенные процессы. Отвечают на вопросы –
  1. Какие ключевые процессы запущены? Как они влияют на загруженность сервера?
  2. Есть ли процессы, отбирающие ресурсы у других процессов?
  3. Можно ли разнести их по разным серверам?

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

Приложение

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

LayerBreakdown

  • Время, проведенное на различных логических уровнях. Отвечает на вопросы –
  1. На каких уровнях приложение проводит больше времени при росте нагрузки?
  2. Какие уровни масштабируются, а какие нет?
  • Количество обращений / вызовов к уровню. Отвечает на вопросы –
  1. Как часто вызываются внутренние веб-сервисы?
  2. Как часто идут обращения к критическим API, например, Hibernate, Springи т д.

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

call_graph

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

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

Команда ALG DevOps Team будет благодарна за ответы на следующие вопросы:

ALG_DevOps_Team