Тестирование и анализ производительности с помощью сервера приложений WebSphere

Сервер приложений IBM® WebSphere® поддерживает постоянно растущий спектр приложений, каждое из которых обладает своим уникальным набором возможностей, требований и сервисов. Надлежащее тестирование и анализ каждого из этих приложений чрезвычайно важны для реализации их максимального потенциала. В настоящей статье дается ряд практических рекомендаций по созданию тестов производительности, сравнению результатов для нескольких приложений или разных условий исполнения и выявлению узких мест с помощью бесплатных инструментов IBM. Описанные здесь методы применимы ко всем версиям сервера приложений WebSphere, включая недавно выпущенную версию WebSphere Application Server V8.5. Из журнала IBM WebSphere Developer Technical Journal.

Дэвид Хэа, программист-консультант, IBM

Дэвид Хэа (David Hare) –программист-консультант группы IBM WebSphere Application Server Performance and Benchmarking, расположенной в Рисерч-Трайэнгл Парк в Северной Каролине. Основными направлениями его работы являются оценка производительности с помощью DayTrader, настройка производительности и новая программа Liberty Profile.



13.06.2013

Введение

Задаетесь ли вы какими-либо из приведенных ниже вопросов?

  • В настоящее время мы не тестируем производительность. Мы бы хотели этим заняться, но даже не знаем, с чего начать.
  • Наше приложение работало отлично, но после того, как разработчики прислали обновленную версию, мы замечаем увеличение загрузки центрального процессора (ЦП) на сервере. Отчего возросла загрузка ЦП?
  • Мы перешли с версии 2.0 на версию 3.0, и время отклика приложения увеличилось в три раза. С чем связаны эти задержки?
  • В следующие три месяца наше приложение должно будет поддерживать на 40 % больше пользователей. Как к этому подготовиться, помимо простого добавления в кластер новых компьютеров?

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

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

Почему тесты производительности так важны

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

Другим плюсом такого подхода к тестированию производительности является возможность настройки среды (операционной системы, JVM, сервера приложений, приложения, базы данных и т.п.) на максимальную производительность. Только соответствующее тестирование производительности позволяет оценить настраиваемые параметры и определить, дают ли они какой-либо эффект. Многие пользователи устанавливают размер кучи JVM в соответствии с рекомендациями разработчиков и не настраивают никаких иных параметров, поскольку не считают это необходимым. Возможно, вы удивитесь, узнав, что иногда можно сократить ресурсы оборудования вдвое по сравнению с ненастроенной системой, просто выполнив элементарную настройку Именно это и подтверждает данная статья.

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

В дополнение к пошаговому тестированию в ходе разработки и удобству настройки важным преимуществом всестороннего тестирования производительности является возможность сравнения результатов для нескольких приложений или разных условий исполнения. В ходе тестирования производительности регистрируются ключевые показатели (которые мы обсудим ниже), которые позволяют администраторам глубже вникать в суть потенциальных проблем. Как мы уже говорили, многие пользователи не готовы к выявлению источников проблем, возникающих при переходе к новой версии приложения, поскольку они никогда не тестировали производительность и не регистрировали ключевые системные характеристики предыдущей версии. Без этого вам, скорее всего, придется настроить сервер с предыдущей версией приложения и использовать его в качестве точки отсчета. Наличие зарегистрированных данных существенно упрощает анализ причин ухудшения.


Рекомендованные методики тестирования производительности

Существуют две фундаментальные методики тестирования производительности, которые кратко можно описать так:

  • Варьирование числа пользователей (или клиентской нагрузки). Производственные среды обычно характеризуются меняющимся в течение дня числом активных пользователей. Качественное тестирование гарантирует хорошую работу приложения в условиях малых и пиковых нагрузок (например, в «черную пятницу»). Это может означать изменение промежутков между запросами и изменение числа обращающихся к приложению активных пользователей. Одним из наилучших методов оценки является выполнение тестов с 1 активным пользователем, 2 пользователями, 4 пользователями, 8 пользователями и т.д. Позже мы изучим этот метод на практическом примере.
  • Регистрация ключевых системных характеристик и показателей производительности. Существует несколько важных показателей, которые следует регистрировать для всех сценариев. Наиболее важными показателями, которые надо регистрировать в каждом тесте производительности, являются:
    • пропускная способность (число запросов в секунду);
    • время реакции;
    • процент загрузки ЦП серверного компьютера;
    • процент загрузки ЦП других компьютеров (Web-сервера, системы управления нагрузкой, базы данных и т.п.).

Пропускную способность и время реакции можно измерять любым инструментом для управления нагрузкой. Загрузку ЦП, памяти, дискового интерфейса и сетевой трафик можно измерять такими инструментами, как vmstat или nmon в Linux® или AIX®, или с помощью Диспетчера задач в Windows®. Кроме упомянутых характеристик важно также регистрировать всю информацию системного уровня. Сюда входят информация уровня операционной системы, число активных ядер, объем доступной памяти (ОЗУ), данные о версии Java™, информация о версии сервера приложений WebSphere и все использованные настройки. Регистрация всех этих параметров позволяет производить быстрое сравнение сценариев, даже если тестирование выполнялось с промежутком в несколько лет.

Многие пользователи не обладают достаточным оборудованием для воспроизведения своей производственной среды в испытательной среде того же размера. В таких случаях рекомендуется масштабировать тесты производительности в соответствии с имеющимися ресурсами. Например, предположим, что производственная среда состоит из десяти физических компьютеров, на каждом из которых работают два экземпляра сервера приложений WebSphere. Если для тестирования доступен лишь один физический компьютер, этот компьютер нужно настроить так, чтобы его конфигурация как можно ближе соответствовала конфигурации производственного компьютера, и нагрузка, используемая в ходе тестирования, должна составлять примерно 10 % от предполагаемой производственной нагрузки. В конечном итоге тест производительности нужно выполнять с нарастающей нагрузкой, чтобы воспроизвести полную производственную среду. Этот способ позволяет протестировать и другие процессы, такие как обращения к базе данных и LDAP.


Сценарии тестирования и системы управления нагрузкой

Прежде чем выполнять тесты производительности и отыскивать узкие места приложений, нужно написать эффективные сценарии тестирования. Качество результатов и анализа напрямую зависит от качества сценария тестирования, который использовался для их получения, поэтому нужно отнестись к этому шагу очень серьезно. Тестирование ветвей кода в условиях, когда обращения пользователей занимают всего 10 % времени, будет далеко не так эффективно, как тестирование в условиях полной нагрузки. Сосредоточьтесь в первую очередь на самых популярных ветвях кода, а уже затем создавайте тесты для тестирования менее загруженных ветвей. Уделив время тщательному проектированию тестов, вы действительно повысите их качество и сможете создать тесты, имитирующие реальную работу пользователей. Эта статья на портале developerWorks является отличным введением в написание сценариев испытания производительности.

После разработки концепции сценария тестирования его нужно воплотить в жизнь с помощью инструмента для управления нагрузкой. Существует множество таких инструментов, включая IBM Rational Performance Tester и инструмент с открытым исходным кодом Jmeter компании Apache. Последний мы и будем использовать в этой статье.


Пример испытания DayTrader

Если вам приходилось читать мои статьи на портале developerWorks, вы, вероятно, уже знакомы с приложением для измерения производительности Trade, или DayTrader. Приложение Apache DayTrader Performance Benchmark Sample имитирует простое приложение для продажи акций, которое позволяет пользователям входить в систему и выходить из нее, просматривать свои документы, читать биржевые сводки, покупать и продавать акции и управлять своей учетной записью. DayTrader является не только прекрасным приложением для функционального тестирования, но и предлагает стандартный набор рабочих нагрузок для измерения производительности на уровне сервера приложений и компонентов.

DayTrader построен на основе базовых технологий Java EE, которые включают сервлеты Java и страницы JavaServer™ (JSP) для уровня представления и интерфейс Java для СУБД (JDBC), службу сообщений Java (JMS), Enterprise JavaBeans (EJB) и управляемые сообщениями компоненты (MDB) для управления серверной СУБД и уровнем сохраняемости. На рисунке 1 приведена общая схема архитектуры этого приложения.

Рисунок 1. Архитектура приложения DayTrader
Figure 1. DayTrader application overview

Корпорация IBM выложила для загрузки образцовый пакет DayTrader, который включает приложение DayTrader и необходимые дескрипторы развертывания. Этот пакет можно устанавливать на WebSphere Application Server V7.0 и более новых версий.

В данном примере образцовое приложение разворачивается поверх базового экземпляра WebSphere Application Server V8.5. Одной из полезных функций DayTrader является ссылка TradeScenarioServlet на вкладке Configuration (Параметры). Она вызывает сервлет, имитирующий работу группы Web-пользователей, случайным образом генерируя некоторые операции DayTrader для каждого пользователя, обращающегося к сервлету. (Например, один пользователь может просматривать свои документы, другой — покупать акции, третий — просматривать котировки и т.д.) Это гарантирует, что во время теста DayTrader будет исполнять все основные операции, а в силу случайного характера исполнения все операции выполняются примерно равное число раз. Существует множество статей, описывающих применение инструмента JMeter для написания очень сложных тестов производительности, в которых можно точно описать, сколько раз и в каком порядке должна выполняться та или иная операция, но в настоящей статье мы будем придерживаться относительно простого сценария тестирования и использовать TradeScenarioServlet.


Применение JMeter

Чтобы настроить Jmeter и выполнить с его помощью тест производительности, проделайте следующее:

  1. Установите Jmeter. Указав свою директорию java, запустите JMeter из директории <JMeter_Home>/bin/ с помощью командного файла jmeter.sh или jmeter.bat. Вы увидите панель, аналогичную той, что показана на рисунке 2.
    Рисунок 2. Стандартная панель JMeter
    Figure 2. JMeter default view
  2. Щелкните правой кнопкой по Test Plan(План тестирования) и выберите пункт Add > Thread Group (Добавить > Группа потоков). Здесь вы определяете число имитируемых пользователей. Для начала используйте такие значения (рисунок 3):
    • Number of Threads (users) (Число потоков (пользователей)): 1;
    • Loop Count (Число циклов): Forever (Бесконечно).
    Рисунок 3. Представление группы потоков в JMeter
    Figure 3. JMeter Thread Group view
  3. Щелкните правой кнопкой по только что созданной группе потоков и выберите пункт Add > Sampler (Добавить > Шаблон). Шаблон определяет тип нагрузки, которую вы хотите применить. Имеются шаблоны для HTTP-запросов, JMS-запросов, сообщений Web-сервисов и т.п. Все имеющиеся шаблоны описаны в руководстве пользователя JMeter. Поскольку DayTrader поддерживает Web-трафик, в данном примере мы будем использовать HTTP-запросы. Укажите имя хоста, порт и путь в соответствии со своей конфигурацией (рисунок 4).
    Рисунок 4. HTTP-запрос
    Figure 4. HTTP request
  4. Щелкните правой кнопкой по только что созданному HTTP-запросу и выберите пункт Add > Timer (Добавить > Таймер). Таймер вставляет «паузу» между запросами. Это имитирует работу пользователя на странице, который щелкает на объекте и затем некоторое время читает информацию, прежде чем сделать следующий запрос. Имеется несколько готовых таймеров разного уровня сложности, от таймеров фиксированной задержки до задержки, распределенной по закону Гаусса или Пуассона. Все имеющиеся таймеры описаны в руководстве пользователя JMeter В этом простом примере мы создадим постоянный таймер длительностью 5 мс.
  5. Щелкните правой кнопкой по группе потоков и выберите пункт Add > Listener > Summary Report (Добавить > Слушатель > Сводный отчет). При этом отобразятся результаты измерения времени реакции и пропускной способности во время исполнения теста.
  6. Сохраните настройки в файле для обеспечения возможности последующей загрузки.

Запуск теста

Прежде чем запускать инструмент управления нагрузкой, всегда проверяйте, что приложение работает в браузере. Когда будете готовы, щелкните по зеленой стрелке или по Run > Start (Исполнение > Пуск). Теперь JMeter подключит одного клиента к указанному вами серверу и будет делать паузу 5 мс после каждого запроса. Щелкнув по Summary Report (Сводный отчет), вы сможете следить за результатами во время исполнения теста.

Обратите внимание, что в течение некоторого времени производительность нарастает; это называется периодом «разогрева» и связано с тем, что JRE необходимо некоторое время на загрузку всех классов, а JIT нужно время на выполнение оптимизации. В конце концов производительность стабилизируется и достигает некоторого фиксированного значения (колеблющегося в пределах нескольких запросов в секунду). В зависимости от сложности теста период разогрева может занять от 30 секунд до 30 минут.

Во время исполнения теста откройте терминал (Linux или AIX) и подайте команду vmstat 5, которая будет отображать системные характеристики каждые 5 секунд (листинг 1).

Листинг 1
[root@spice3 bin]# vmstat 5 
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- 
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 
 0  0      0 8235164 104920 500956    0    0    13    11   44  154  8  5 86  0  0 
 0  0      0 8235164 104928 500956    0    0     0     3 8030 4987  6  1 93  0  0 
 1  0      0 8235040 104936 500956    0    0     0     3 7982 4944  5  1 94  0  0 
 0  0      0 8233116 104936 500960    0    0     0     6 8126 5020  7  1 92  0  0 
 0  0      0 8231068 104944 500960    0    0     0     6 7952 4939  6  1 93  0  0 
 0  0      0 8231316 104952 500960    0    0     0     3 7761 4819  5  1 94  0  0 
Example vmstat output showing ~7% CPU utilization.

Если вы используете Windows, щелкните правой кнопкой по панели задач, выберите Диспетчер задач (Task Manager) и перейдите на вкладку Быстродействие (Performance). Когда производительность в JMeter достигнет стабильного значения, запишите загрузку ЦП сервера, на котором запущен сервер приложений WebSphere и любой другой сервер приложений, и затем остановите тест Jmeter, щелкнув по красному значку остановки или выбрав пункт меню Run > Stop(Исполнение > Стоп). Сводный отчет JMeter должен выглядеть примерно так, как показано на рисунке 5.

Рисунок 5. Сводный отчет JMeter
Figure 5. JMeter Summary Report view

Занесите в электронную таблицу значение производительности (93,9 запросов/с) и среднее время реакции (4 мс). Если вам нужна более детальная информация, запишите также минимальное и максимальное значения и стандартное отклонение времени реакции.

Записав все результаты, выберите Run > Clear (Исполнение > Очистить) и очистите сводную таблицу. На этом тест для одного пользователя завершен. Теперь просто повторите описанные выше шаги для числа пользователей 2, 4, 8 и т.п. С каждым шагом добавления пользователей вы будете наблюдать рост производительности. В конце концов вы увидите, что производительность перестает расти и может даже начать снижаться. Как только вы достигнете плоского участка (и, возможно, снижения), тест можно прекращать.


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

Выполнив описанные выше шаги, вы получите электронную таблицу, которая должна выглядеть примерно так, как показано на рисунке 6. (Результаты сильно зависят от приложения DayTrader и от среды, в которой оно запускалось. Скорее всего, ваши результаты будут выглядеть совершенно иначе.)

Рисунок 6. Результаты тестирования – таблица
Figure 6. Test Results – Table view

Представление необработанных данных в табличной форме дает целый ряд преимуществ, однако не менее полезно представить результаты в графическом виде. Одним из лучших способов является построение диаграммы рассеяния по осям XY. Такая диаграмма существенно упрощает выявление тенденций. На рисунке 7 показана зависимость производительности и загрузки ЦП сервера приложения WebSphere от числа клиентов.

Рисунок 7. Результаты тестирования – график
Figure 7. Test Results – Graph

Приведенный выше рисунок 7 демонстрирует интересные особенности. Во-первых, кривая производительности и кривая загрузки ЦП почти совпадают. Во-вторых, производительность приложения линейно нарастает при изменении числа клиентов от 1 до 500. Это именно то, что мы хотим получить. Однако в интервале от 500 до 1000 клиентов рост производительности начинает медленно снижаться. (Для выявления точного момента начала снижения нужно провести дополнительные тесты с числом пользователей от 500 до 1000.) Дальнейший рост числа клиентов не повышает общей производительности приложения. Эта точка называется точкой насыщения. Это и есть ключевое значение, которое нужно найти во время тестирования производительности. Точка насыщения говорит о том, что вы достигли максимальной производительности для данного приложения, настроек, конфигурации и среды. Увеличение числа пользователей сверх этого значения лишь увеличит время реакции, не повышая общую производительность приложения. Для получения лучшей производительности за пределами этой точки следует внести изменения в код приложения, изменить настройки или среду исполнения.

Зависимость DayTrader от вашего приложения

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

Такой тип тестирования и анализа очень важен для планирования изменения размеров и емкости. Только определив точку насыщения, вы можете точно оценить общую производительность, необходимую для поддержки производственной среды. Часто бывает, что некто говорит: «В этой среде мне нужна поддержка 10000 пользователей» и затем запускает ряд тестов для этого числа клиентов. Как правило, такой подход приводит к возникновению всевозможных условий перегрузки в одном или нескольких компонентах, либо в сервере приложений WebSphere, либо в других инфраструктурных компонентах (сеть, база данных и т.п.). Более продуктивный подход заключается в определении максимальной нагрузки и производительности для одного сервера приложений и последующей настройке среды исполнения и приложения на основе полученной информации. Завершив настройку, вы можете оценить, сколько процессов сервера приложений и физических серверов потребуется для удовлетворения требований масштабируемости.

Сохраните новый тест в JMeter с числом потоков (пользователей), соответствующим найденной вами точке насыщения. Эти сведения можно будет использовать в качестве эталона для сравнения производительности по мере внесения изменений в приложение или среду без повторного полного тестирования масштабируемости. Это не значит, что вам не придется больше тестировать масштабируемость, но запуск теста в точке насыщения даст хорошие результаты для сравнения изменений, которые, скорее всего, не дадут заметного эффекта при меньших нагрузках в условиях неполной загрузки ЦП. Рекомендуется выполнять тест в точке насыщения после внесения минимальных изменений в приложение или настройки, и повторять полный тест масштабируемости после серьезных изменений приложения или среды исполнения.


Средства измерения производительности

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

  • IBM Tivoli® Performance Viewer

    Tivoli Performance Viewer (в консоли администратора) является крайне полезным инструментом для мониторинга сервера приложений WebSphere. Эта статья отлично описывает преимущества применения Tivoli Performance Viewer для оптимальной настройки среды. Кроме того, Tivoli Performance Viewer можно использовать для быстрого выявления узких мест, которые легко устраняются грамотной настройкой.

    Вот несколько простых шагов, которые нужно проделать, чтобы начать работу с Tivoli Performance Viewer:

    1. Перезапустите JMeter с числом пользователей, соответствующим найденной точке насыщения.
    2. Войдите в консоль администратора и выберите Monitoring and Tuning > Performance Viewer > Current Activity (Мониторинг и настройка > Обозреватель производительности > Текущая активность). Щелкните по серверу, который хотите контролировать, и затем разверните Performance Modules(Модули производительности). Откроется список доступных для просмотра модулей производительности.
    3. Информативность модулей зависит от характеристик конкретного приложения. Для DayTrader или любого иного приложения, основанного на Web-трафике, начните с модуля Thread Pools > WebContainer (Пулы потоков > Web-контейнер). Щелкнув по этому полю, нажмите на расположенную вверху кнопкуView Module (Обзор модуля). Откроется график, аналогичный тому, что показан на рисунке 8, автоматически выводящий новые данные каждые 8 секунд по мере выполнения теста JMeter.
      Рисунок 8. Данные WebContainer PMI
      Figure 8. WebContainer PMI data

      Этот пример показывает, что размер пула потоков WebContainer равен 50 потокам, тогда как используется примерно 32. Это говорит о том, что размер пула потоков WebContainer для текущей рабочей нагрузки не является узким местом. Если активное значение колеблется в диапазоне 45–50, то размер пула потоков WebContainer может быть узким местом. В этом случае лучше увеличить размер пула потоков WebContainer и, повторив тест, посмотреть, улучшилась ли производительность. Если производительность повысилась, то, вероятно, стоит повторить полный тест масштабируемости и заново определить точку отсчета.

    4. Повторите шаг 3 для других модулей, применимых к вашему приложению. Для транзакционной системы, подобной DayTrader, еще одним модулем, на который стоит взглянуть, является модуль информации о пуле подключений JDBC (JDBC Connection Pools). Разверните ветвь JDBC Connection Pools > (ваш драйвер JDBC) и выберите имя вашего источника данных JNDI. Щелкните по кнопке View Module. Откроется график, подобный тому, что показан на рисунке 9.
      Рисунок 9. Данные DataSource PMI
      Figure 9. DataSource PMI data

      Параметры, показанные на этом графике, отличаются от выбранных по умолчанию. Параметры PoolSize (размер пула), FreePoolSize (размер свободного пула) и WaitingThreadCount (число ожидающих потоков) позволяют увидеть, не является ли ваш пул подключений источником конфликтов, и не стоят ли потоки WebContainer в очереди, ожидая подключения к базе данных. В приведенном выше примере размер пула подключений равен фиксированному значению 50 (определяется настройкой). Размер свободного пула колеблется в районе 20, а это значит, что в каждый момент времени активны примерно 30 подключений. В результате число ожидающих потоков равно 0, что говорит об отсутствии потоков WebContainer, ожидающих подключения к базе данных. Это подтверждает, что размер пула подключений JDBC не является узким местом. Если бы размер свободного пула равнялся 0 и число ожидающих потоков было больше нуля, то вам следовало бы повторить тест с большим размером пула подключений.

    Продолжайте выполнять этот процесс с другими модулями, подходящими для мониторинга вашего приложения. В статье Еретик WebSphere: подготовка к отказу приведен обширный перечень статистических показателей, мониторинг которых может оказаться очень полезным. Выполнив это упражнение, можно перейти к более детальному анализу с помощью IBM Health Center.
  • Средства мониторинга и диагностики IBM для Java – Health Center

    Пакет мониторинга и диагностики IBM для Java – Health Center (называемый в дальнейшем Health Center и являющийся частью IBM Support Assistant) представляет собой инструмент, рекомендованный для детального анализа производительности в сервере приложений WebSphere. Health Center предоставляет обширную информацию о производительности сервера, в том числе следующие характеристики:

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

    Health Center входит в состав IBM Support Assistant (ISA), который доступен для бесплатной загрузки. Обязательно устанавливайте ISA не на тот компьютер, где работает сервер приложений, иначе Health Center будет забирать ресурсы у процесса сервера приложений, и ваши результаты могут оказаться неточными. Health Center может работать в интерактивном и в «слепом» режимах, когда информация сохраняется в файле для дальнейшего просмотра. В данном примере мы будем использовать интерактивный режим.

    Чтобы запустить Health Center:

    1. Перезапустите процесс сервера приложений, о котором вы хотите получить детальную информацию, с универсальным аргументом JVM -Xhealthcenter.
    2. Запустите ISA. По окончанию загрузки выберите Analyze Problem (Анализ проблемы). (Если вы этого еще не делали, то сообщите ISA, что вас интересуют инструменты для сервера приложений WebSphere).
    3. Выберите IBM Monitoring and Diagnostic Tools for Java – Health Center и щелкните по кнопке Launch (Запуск) (рисунок 10).
      Рисунок 10. Запуск Health Center из ISA
      Figure 10. Launching Health Center from ISA
    4. Откроется мастер подключений. Щелкните по кнопке Next (Далее). Укажите имя или IP-адрес хоста, на котором запущен сервер приложений. По умолчанию используется порт 1972. Если вас интересуют особые требования к безопасности, укажите их здесь, в противном случае щелкните по Next. Если имя хоста и порт будут обнаружены, щелкните по Next еще раз, в противном случае выясните, почему подключение не работает. Если все прошло успешно, Health Center будет выглядеть примерно так, как показано на рисунке 11.
      Рисунок 11. Стандартный вид Health Center
      Figure 11. Health Center default view
    5. Разверните Health Center на весь экран и пощелкайте по кнопкам, чтобы познакомиться с его возможностями. Теперь вы готовы к выполнению детального анализа (что будет описано в следующем разделе). Перезапустите JMeter с числом пользователей, соответствующим точке насыщения. Health Center будет динамически обновляться по мере поступления новой информации. Прежде чем продолжить, позвольте JMeter пройти через период разогрева.

Анализ сбора мусора

Первым шагом анализа производительности любого приложения Java всегда является изучение статистики сбора мусора. Если Health Center запущен и работает, это делается совсем просто.

Щелкните в окне Health Center по ссылке Garbage Collection (Сбор мусора). Появится окно, показанное на рисунке 12.

Рисунок 12. Health Center – обзор сбора мусора
Figure 12. Health Center – Garbage Collection view

Для проведения начального анализа следует обратить внимание на две важные вещи:

  • Расположенная в левом нижнем углу секция Analysis and Recommendations (Анализ и рекомендации) содержит полезные советы и информацию, полученную от встроенных интеллектуальных функций Health Center. Эти советы могут содержать рекомендации по выбору политики сбора мусора и размера кучи, информацию об утечках памяти или системных вызовах System.gc() и многое другое. На рисунке 12 эта секция сообщает, что оптимальной политикой GC для DayTrader является gencon, и что утечки памяти в приложении, по всей видимости, отсутствуют. Это всегда является замечательной отправной точкой.
  • Расположенная в нижней части окна панель Summary (Сводная информация) содержит наиболее важные статистические показатели, на которые следует обратить внимание, начиная с «Proportion of time spent in Garbage Collection pauses» (Доля времени, уходящая на сбор мусора). Этот статистический показатель указывает, какой процент времени ваше приложение простаивает из-за сбора мусора. Это значение должно быть как можно меньше, в идеале менее 2–3 %. Если оно равно 10 %, то вы можете повысить производительность до 10 %, оптимизируя размер кучи JVM и политику сбора мусора. Как уже говорилось, это исследование является превосходным примером, который покажет вам, как пройти через весь процесс настройки.

Несколько советов, которые помогут отыскать наиболее полезные данные:

  • По оси X диаграммы, показанной на рисунке 12, отложено время, прошедшее с момента запуска сервера. Это позволяет сопоставлять значения с операциями, выполняемыми в определенное время суток. Ось X можно изменить, выбрав в контекстном меню пункт context menu > Change Units > X-Axis > Time (Изменить единицы > Ось Х > Время).
  • Вы можете обрезать данные, чтобы исключить период разогрева и получить более точное представление о том, что происходит в нормальных условиях работы. Для этого выберите Data > Crop Data (Данные > Обрезать), чтобы отрезать начало и конец, или просто Data > Reset Data (Данные > Сбросить), чтобы очистить все данные вплоть до этой точки.
  • Для выполнения более детального анализа щелкните по вкладке Samples by object (Выборка по объектам). Это позволит увидеть, какие объекты были зарезервированы, сколько объектов каждого типа зарезервировано, и чему равен общий размер объектов. Здесь даже есть возможность поиска по имени пакета или объекта. Пример показан на рисунке 13. На основании этих результатов можно сделать вывод о необходимости просмотра кода приложения и выяснить, нельзя ли уменьшит число переменных типа BigDecimal и BigInteger.
Рисунок 13. Health Center – представление выборки по объектам
Figure 13. Health Center – Samples By Object view

Анализ профиля метода

При работающей системе управления нагрузкой щелкните по ссылке Profiling(Анализ профиля). Отроется окно Method Profiling (Анализ профиля метода), пример которого показан на рисунке 14.

Рисунок 14. Health Center – окно анализа профиля метода
Figure 14. Health Center – Method Profiling view

Таблица Method Profile (Профиль метода) показывает, какой из методов больше всего расходует вычислительные ресурсы. Здесь приведено общее представление всей JVM, а не отдельного приложения, поэтому тут присутствует информация о драйверах базы данных, контейнерах сервера приложений WebSphere Application и т.п. Это представление очень полезно, так как позволяет увидеть общую картину того, что происходит на сервере. Как и в предыдущем примере со сбором мусора, в данном случае лучше начинать с раздела Analysis and Recommendations. Эта панель покажет все методы, потребляющие больше процессорных циклов, чем остальные. В приведенном выше примере вам сообщают о том, что указать методы для оптимизации не представляется возможным, поскольку все циклы достаточно равномерно распределись между всеми методами. Если здесь будут указаны один или два метода, следует изучить код этих методов и подумать, как их можно оптимизировать или как сократить число их вызовов.

Для более глубокого погружения в тему нужно уметь интерпретировать данные этой таблицы. В этом может помочь документация Health Center, которую можно открыть, выбрав в меню Help > Help Contents(Справка > Содержание), прокрутив страницы вниз и развернув книгу Tool: IBM Monitoring and Diagnostic Tools for Java - Health Center. В документации сказано:

Методы с большим значением Self (%) считаются «горячими», и являются хорошими кандидатами для оптимизации. Даже незначительное повышение эффективности таких методов может оказать большое влияние на производительность. Оптимизировать методы можно путем уменьшения объема выполняемой ими работы или сокращения числа обращений к этим методам. Методы, расположенные ближе к концу таблицы – плохие кандидаты для оптимизации. Даже существенное улучшение их эффективности вряд ли скажется на производительности, поскольку они не сильно загружают процессор.

Ниже приведено описание каждого столбца этой таблицы:

Таблица 1. Таблица профилей методов
СтолбецОписание
Self (%)Процент выборок, при взятии которых данный метод работал на вершине стека. Это значение является хорошим показателем расхода процессорных ресурсов.
SelfГрафическое представление столбца Self (%). Чем длиннее и краснее полоса, тем «горячее» метод.
Tree (%)Процент выборок, при взятии которых метод находился в любом месте стека вызовов. Это значение показывает процент времени, в течение которого обрабатывался этот метод и вызываемые им методы (потомки). Это значение позволяет выявлять области приложения, на которые затрачивается больше всего процессорного времени.
TreeГрафическое представление столбца Tree (%). Чем длиннее и краснее полоса, тем «горячее» метод.
SamplesЧисло выборок, при взятии которых метод работал на вершине стека.
MethodПолная информация о методе, включая имя пакета, имя класса, имя метода, аргументы и тип возвращаемого значения.

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

  • Щелкнув по строке таблицы, можно увидеть в нижней панели полный путь вызова метода.
  • Вкладка Timeline (Шкала времени) показывает, когда исполнялся данный метод в исследуемый период. Это может оказаться полезным, так как позволяет не рассматривать ранние события профиля, которые могли происходить, например, во время разогрева.
  • Текстовое поле Filter methods (Фильтрация методов) позволяет выполнять поиск указанных классов и отфильтровывать остальную часть профиля. Это может быть полезным для выделения деталей вашего конкретного приложения путем удаления всех других, не относящихся к нему классов. Например, на рисунке 15 показан профиль, отфильтрованный по «daytrader», поскольку имена пакетов всех классов приложения DayTrader содержат текст «daytrader». Это позволяет сосредоточиться на ресурсоемких методах вашего конкретного приложения.
Рисунок 15. Отфильтрованное представление профилей методов DayTrader
Figure 15. DayTrader filtered Method Profile view

Если приложение содержит некоторый метод, потребляющий много процессорных циклов, Health Center пометит его как хорошего кандидата для оптимизации на панели Analysis and Recommendations. Пример этого приведен на рисунке 16.

Рисунок 16. Пример кандидата для оптимизации
Figure 16. Optimization candidate example

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


Анализ блокировок

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

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

При запуске приложений на компьютерах с большим числом ядер (4+) анализ блокировки становится очень важен, так как позволяет гарантировать, что приложение способно масштабироваться и использовать все доступные вычислительные ресурсы. (Понятно, что ценность такого анализа невелика, если приложение работает на одноядерном компьютере.) Представление блокировки анализирует профили блокировки и помогает выявлять конфликты блокировок в приложениях или в среде исполнения Java, мешающие масштабированию приложения. После щелчка по ссылке Locking (блокировка) открывается панель, аналогичная показанной на рисунке 17.

Рисунок 17. Health Center – представление блокировки
Figure 17. Health Center – Locking view

На первый взгляд представление Monitors (Мониторы) может показаться сложным. Однако в документации на Health Center приведено подробное описание данной панели, которое поможет понять все эти параметры. В таблице 2 приведено описание столбцов таблицы мониторов.

Таблица 2. Мониторы
СтолбецОписание
% missПроцент от общего числа операций Get (считываний данных), для которых поток, пытающийся получить замок синхронизированного кода, вынужден блокироваться до получения доступа к замку.
Gets:Общее число получений доступа к замку, пока он был взведен
Slow:Общее число нерекурсивных захватов замка, когда запрашивающий поток был вынужден ждать освобождения замка, поскольку тот уже принадлежал другому потоку.
Recursive:Общее число рекурсивных захватов. Рекурсивный захват возникает в том случае, когда запрашивающий поток уже владеет этим монитором.
% util:Время, в течение которого удерживался замок, поделенное на время, в течение которого удерживался выход
Average hold time:Среднее время удержания замка потоком (владения замком). Например, время, проведенное в синхронизированном блоке, измеренное в периодах тактовой частоты процессора.
Name:Имя монитора. Если имя неизвестно, этот столбец остается пустым

В таблице перечислены все мониторы Java, которые были взведены хотя бы раз. Главный интерес представляет столбец % miss. Высокое значение % miss свидетельствует о частых конфликтах в синхронизированных ресурсах, защищаемых блокировкой. Эти конфликты могут помешать дальнейшему масштабированию приложения Java.

Если замок имеет высокое значение % miss, обратите внимание на среднее время удержания и значение % util. Вот несколько советов:

  • если значения % util и среднего времени удержания велики, то, вероятно, нужно уменьшить объем работы, выполняемой во время удержания замка;
  • если % util велик, а среднее время удержание мало, то, вероятно, нужно сделать ресурсы, защищенные замком, более гранулированными и разделить этот замок на несколько замков.

Заключение

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

Хотя приложение DayTrader может быть непохоже на ваше приложение, описанные в настоящей статье методы тестирования производительности и выявления узких мест могут с тем же успехом применяться и к вашему приложению. Тестирование в условиях малой нагрузки, соответствующей периодам менее интенсивного использования, и в условиях высокой нагрузки, соответствующей периодам пиковой загрузки, играет важную роль в понимании характеристик вашего приложения. Регистрация ключевых показателей для последующего сравнения по мере изменения приложения или среды очень важна для понимания причин ухудшения производительности. И, наконец, инструмент IBM Health Center существенно упрощает анализ производительности, предлагая средства анализа сбора мусора, профилей методов и профилей блокировки, помогающие максимизировать эффективность работы приложения.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


  • Bluemix

    Узнайте больше информации о платформе IBM Bluemix, создавайте приложения, используя готовые решения!

  • developerWorks Premium

    Эксклюзивные инструменты для построения вашего приложения. Узнать больше.

  • Библиотека документов

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=933961
ArticleTitle=Тестирование и анализ производительности с помощью сервера приложений WebSphere
publish-date=06132013