Использование IBM Rational Performance Tester для проведения нагрузочных испытаний смоделированного книжного интернет-магазина

В этой статье обобщается опыт группы IBM Platform Evaluation Test по миграции с опытной разработки IBM Web Performance Tools (WPT) на Linux-версию IBM Rational Performance Tester, в который теперь включена функциональность WPT. Инструменты моделирования пользовательской активности играют ключевую роль в нагрузочном тестировании смоделированного сайта книжного интернет-магазина. В этот отчёт включены ранее недокументированные вопросы работы RPT на Linux и стратегии расширения RPT для использования Web-сервисов и базы данных IBM DB2 для моделирования пользовательского ввода. Результаты показывают, что Rational Performance Tester выполняет на 236% больше транзакций, чем WPT за то же время. Статья предназначена пользователям среднего уровня и опытным пользователям Rational Performance Tester или аналогичного ПО.

В этой статье обобщается опыт группы IBM Platform Evaluation Test (PET) по реализации версии IBM Rational Performance Tester для операционной системы Linux для смоделированного Web-сайта интернет-магазина. До того, как нам стал доступен Rational Performance Tester, наш выбор ПО для моделирования активности пользователя был ограничен некоммерческими продуктами, например опытной разработкой IBM Web Performance Tools и Siege. Оба эти продукта выполняют основные функции Web-сессий, например запись и воспроизведение, но им не хватает многих полезных функций, доступных в коммерческих продуктах, например Rational Performance Tester. Мы обсуждаем наш первый опыт работы с Rational Performance Tester и сравниваем его с WPT в качестве базового инструмента моделирования активности пользователя. Мы также обсуждаем наш опыт использования пула данных и возможностей написания собственного кода. Наконец, мы анализируем потенциал дополнительных расширений среды нагрузочных испытаний сайта книжного магазина.

Обзор сайта книжного магазина

Сайт книжного магазина является Web-приложением IBM zipSeries, используемым только внутри IBM, который моделирует большой интернет-магазин типа BarnesAndNoble.com. Это сложная, многоуровневая, мультиплатформенная среда, предназначенная для эмуляции реального сценария заказчика. Книжный магазин функционирует на оборудовании IBM Systems p, z, i и x, на котором работают ПО IBM DB2, IBM WebSphere Application Server и IBM WebSphere MQSeries. Мы используем WPT для моделирования активности миллионов клиентов магазина и нам удаётся находить и разрешать проблемы с ПО, оборудованием и интеграцией до того, как с ними столкнутся реальные покупатели.

Описание инструментов моделирования активности пользователей

IBM alphaWorks Web Performance Tools

Мы оценивали три инструмента для тестирования сайтов: IBM Web Performance Tools, Siege и IBM Rational Performance Tester.

Продукт IBM Web Performance Tools (WPT) создавался как опытная разработка IBM alphaWorks, подразделения IBM по новейшим технологиям. WPT более не улучшается, потому что в ходе испытаний он доказал свою полезность, и его пустили в длительную разработку как коммерческий продукт. Следовательно, вся функциональность была включена в Rational Performance Tester.

WPT изначально работал на платформе IBM AIX и был известен под названием AKstress, но в самых последних его релизах использовалось название Web Performance Tools. Новейшие версии доступны на других платформах, в том числе в операционной системе Linux. WPT состоит из двух основных программ: stress (нагрузка) и record (запись).

• Инструмент stress - это простой, высокопроизводительный, поточный HTTP-движок, который моделирует очень высокую нагрузку от HTTP-клиентов. Он может работать со скриптами, выдавать полезную статистику и вести журналы.
• Инструмент record облегчает создание скриптов для нагрузочных тестов.

Siege

Siege - это ПО, распространяющееся под лицензией GPL, возможности которого аналогичны WPT. Со временем мы заметили, что его производительность также аналогична WPT. Следовательно, мы полагаем, что формальное сравнение этого продукта с Rational Performance Tester было бы излишним.

IBM Rational Performance Tester

Это коммерческий продукт IBM для создания пользовательской нагрузки. Он функционирует как плагин для платформы разработки ПО IBM (SDP) и в настоящее время поддерживается только для операционных систем Microsoft Windows и Linux. Rational Performance Tester включает полнофункциональную копию IBM Rational ClearCase LT, плюс следующие ключевые функции:

• Визуальный редактор тестов для создания, изменения и выполнения рабочей нагрузки
• Возможность запускать множество различных моделирований действий пользователей одновременно
• Развёртываемый исполняемый агент, распределяющий тестовые задачи по узлам
• Немедленные отчёты о производительности и пропускной способности
• Автоматическая идентификация и поддержка динамических ответов сервера
• Случайный ввод с помощью пулов данных
• Сбор и визуализация данных о ресурсах сервера
• HTML-режим просмотра Web-страниц, посещённых во время записи теста
• Вставка Java-кода для гибкой настройки тестов

Предварительные требования для успешного моделирования активности пользователей книжного магазина

Одним из ключевых аспектов ПО zipSeries является бесперебойная работа при высокой нагрузке. В прошлом мы подвергали его непрерывному использованию в течение многих недель, что помогло определить, какие компоненты книжного магазина имеют тенденцию к отказу. Поэтому для нашей первоначальной фазы тестирования мы устанавливаем следующие задачи и требования для Rational Performance Tester:

• Он должен быть функционально приемлемым. Он должен быть в состоянии воспроизводить заданный набор захваченных экранов для эталонного тестирования и сосуществования продуктов.
• Он должен быть в состоянии надёжно работать в течение длительных периодов времени. Как минимум, он должен работать недели без ручного вмешательства.
• Он должен быть в состоянии создавать адекватную рабочую нагрузку. Для сравнения в качестве эталона будут использоваться уровень транзакций, который в настоящее время генерируется WPT. Таким образом, Rational Performance Tester должен показывать такие же результаты или превосходить текущие показатели в пределах 15%.
• Он должен легко устанавливаться, настраиваться и запускаться. Желательно, чтобы у нас была возможность выполнять скрипты из командной строки, чтобы запускать и останавливать часто используемые тесты.

Рандомизация пользовательского ввода в настоящее время выполняется ПО zipSeries, поскольку WPT, будучи опытной разработкой, имеет ограничения. Следовательно, чтобы точнее смоделировать реальную ситуацию, мы также хотели использовать уникальные функции Rational Performance Tester для добавления рандомизации к тестовому ПО.

Тестовая среда

Мы выполняли разработку под Red Hat Enterprise Linux WS 3 (ядро 2.4.21-40.EL) с помощью IBM Rational Application Developer версии 6.0.1.1 FixPack 2 с Java 1.4.2. Мы также использовали development box для проведения большинства тестов, поэтому ниже в этом отчёте мы называем его «тестовой машиной». Это компьютер IBM NetVista 8305-R8U с 2,4 ГГц процессором Pentium 4, 1 Гб оперативной памяти и 2 Гб своп-файлом и с жёстким диском 35 Гб. Мы выполняли длительные тесты в Red Hat Enterprise Linux AS 3 (ядро 2.4.21-20.ELsmp) на компьютере IBM X345 с двумя 3,2 ГГц процессорами Xeon, 3 Гб оперативной памяти и 2 Гб своп-файлом и 15 Гб места для хранения данных.

Web-среда размещалась на системе IBM POWER 5 ML3, на которой работала AIX V 5.5 TL4 ServicePac 2. В ней выполнялось приложение для книжных интернет-магазинов zipSeries на IBM WebSphere Application Server V 6.0.2, FixPack 7. На обоих серверах БД магазина (Browse [Сервер навигации] и Buy [Сервер покупок]) работала DB2 UDB V 8.1; оборудование соответствовало спецификациям машин для работы с WebSphere Application Server. Для размещения Web-сервисов с целью проведения их тестирования использовалась дополнительная машина с WebSphere Application Server под Red Hat Enterprise Linux AS 3 (ядро 2.6.9-22.0.2.ELsmp). Это была система IBM e325 с двумя 2 ГГц процессорами Opteron, 3 Гб оперативной памяти и 2 Гб своп-файлом и 15 Гб дискового пространства.

Сетевое соединение между двумя нашими тестовыми машинами осуществлялось через оптоволоконный гигабитный Ethernet. Для тестирования мы использовали Linux-версии Web Performance Tools V 1.9.4 и Rational Performance Tester V 6.1.2 FixPack 2.

Опыт реализации

В этом разделе мы описываем проблемы, с которыми мы столкнулись. Имейте в виду, что хотя Rational Performance Tester поддерживается под Linux, он гораздо больше тестировался на платформе Windows. Следовательно, некоторые проблемы, которые мы здесь перечисляем, могут не относиться к Windows-версии.

Установка

Мы загрузили установщик Rational Performance Tester с внутреннего Web-сайта IBM. Установка простая и почти не требует вмешательства, но для её завершения требуется очень много времени - на аналогичном оборудовании рассчитывайте на четыре часа. Сразу после завершения инсталляции потребуется установить обновления для Rational Performance Tester и любого другого ранее установленного программного обеспечения платформы разработки ПО IBM (SDP). Рекомендация: Если у вас есть место на диске, создайте их образы. Если вам когда-либо потребуется переустановить Rational Performance Tester с нуля, это сэкономит вам время.

Запуск Rational Performance Tester

Rational Performance Tester доступен через представление (перспективу) Test SDP. Рекомендация: На платформе Linux интегрированный Web-браузер может работать неправильно, если вы не установите переменную окружения MOZILLA_FIVE_HOME. Она должна ссылаться на директорию установки Mozilla. В нашей системе для разработки такой директорией была /usr/lib/mozilla-1.7.12.

«Падения» рабочего пространства

Иногда SDP может «упасть» или зависнуть, или рабочее пространство может вести себя странно или отказываться вновь открываться. Рекомендация: При закрытой SDP удалите папку .metadata в директории рабочего пространства, снова откройте SDP и импортируйте папки проекта из файловой системы.

Расположение журнала

Сообщения об ошибках часто ссылаются на определённые журналы, хотя не очевидно, где эти журналы находятся. Вот решение: .log-файл в папке .metadata рабочего пространства содержит все сообщения об ошибках, которые отображаются на экране. В нём содержатся определённые исключения, возвращаемые SDP, но не все. Рекомендация:

• Запуская SDP (через rationalsdp.bin), неплохо перенаправить весь вывод в дополнительный файл.
• Существуют также журналы CommonBaseEvents в папке .metadata рабочего пространства. Они содержат главным образом ошибки во время компиляции и предупреждения от SDP. Ошибки выполнения расположены в другом месте, в Журнале выявления отказов (Problem Determination Log). В папке deployment_root рабочего пространства откройте самую последнюю изменённую подпапку и изучите там журналы CommonBaseEvents. Тот, что заканчивается на 00 - самый новый. Иногда записи из Problem Determination Log будут отображаться в истории выполнения тестов/графике, но не всегда.
• Кроме того, некоторые сообщения об ошибках будут отображаться только в истории выполнения, и не будут заноситься в журнал. Во время тестирования по графику обязательно установите в графике опции Problem Determination и Execution History logging в состояние All.

Максимальный размер пула данных

Rational Performance Tester содержит функцию рандомизации данных, вводящихся в форму. Вы можете создать пул данных, чтобы указать, какие значения использовать. Пул данных целиком загружается в память во время выполнения. Эта функция обеспечивает точность выполнения теста. Однако в результате максимальный размер пула данных зависит от количества доступной оперативной памяти. Rational Performance Tester можно настроить так, чтобы он использовал больше системной памяти при помощи аргументов виртуальной машины Java (JVM), но этого недостаточно для очень больших наборов данных (приблизительно 10000 значений на машине с 3 Гб оперативки).

Рекомендация: Мы использовали функцию Custom Code (Создание пользовательского кода) Rational Performance Tester для создания альтернативного метода пула данных, при котором не загружаются принудительно все данные сразу. (См. следующий раздел).

Использование J2EE с функцией Custom Code

В следующем ниже разделе Тесты и процедуры мы рассматриваем более подробно, почему нам понадобилось использовать функциональность Java Platform 2, Enterprise Edition (J2EE), в частности, Web-сервисы. Имейте в виду, что некоторые из этих моментов относятся к подключению любой внешней библиотеки для использования с пользовательским кодом. Рекомендации:

1. Прежде всего, совет: Убедитесь, что программа работает правильно как отдельный проект в IBM Rational Application Developer, прежде чем пытаться использовать её как пользовательский код.
2. Вы обнаружите две записи в вашем файле .classpath проекта Rational Application Developer, которые вам потребуется сохранить на будущее. Переключитесь в перспективу Resource, чтобы увидеть файл .classpath. Первая запись - для WebSphere Runtime Library, а вторая - JAR-файл из библиотеки, которую нужно явно включить, если вы планируете использовать Web-сервисы.

• <classpathentry kind="con" path="com.ibm.wtp.server.java.core.container/ com.ibm.ws.ast.st.runtime.core.runtimeTarget.v60/was.base.v6"/>
• <classpathentry kind="lib" path="/opt/IBM/Rational/SDP/6.0/runtimes/ base_v6/lib/objectpoolimpl.jar"/>

3. После создания пользовательского кода и включения соответствующих записей в файл .classpath вашего тестового проекта, откройте окно Project Properties (Свойства проекта). Подумайте, не включить ли ваш отдельный проект в путь сборки вашего тестового проекта.
4. Выберите JRE System Library и WebSphere V 6.0 Runtime на вкладках Order и Export.
5. Затем закройте Rational Performance Tester, остановите IBM Rational Agent Controller (или RAServer), перезапустите его, а затем перезапустите Rational Performance Tester.
6. Всегда проверяйте, что перед запуском теста на вкладках Order и Export отмечены соответствующие библиотеки. Иногда Rational Performance Tester не сохраняет настройки с вкладок Order и Export. Это особенно заметно, если проект экспортируется, а затем импортируется в новое рабочее пространство.

Если и это не срабатывает в вашем случае, попробуйте явно включить все необходимые JAR-файлы в путь сборки проекта, вместо того, чтобы использовать WebSphere V 6.0 во время выполнения. Если вы используете Web-сервисы, можно включить следующие JAR-файлы:

• bootstrap.jar
• channelfw.jar
• channel.http.jar
• channel.tcp.jar
• commons-discovery.jar
• ffdc.jar
• j2ee.jar
• objectpoolimpl.jar
• runtimefw.jar
• webservices.jar
• wsdl4j.jar

Техподдержка IBM посоветует вам включить все необходимые JAR-файлы в переменную окружения class path перед запуском Rational Performance Tester. Однако в нашем случае это ничего не изменило. Явное включение (JAR) файлов в файл .classpath также не полностью сработало в нашем случае, но это помогло нам лучше понять, что ещё требуется сделать, чтобы всё заработало.

Например, если JVM не может найти класс, необходимый для пользовательского кода во время выполнения теста, IBM Rational Agent Controller проигнорирует пользовательский код, и будет действовать, как будто он вернул null. Когда пользовательский код возвращает null, замена не производится. Вы можете получить, а можете и не получить сообщение об ошибке в истории выполнения теста/графике, когда это произойдёт. Используя метод Class.forName() в пользовательском коде, мы смогли отслеживать ошибки, когда определённый необходимый класс был недоступен Rational Performance Tester во время выполнения.

Даже когда все необходимые классы доступны Rational Agent Controller и Rational Performance Tester во время выполнения, ваша зависящая от J2EE программа может по-прежнему не работать. В нашем случае, вызов ServiceFactory.newInstance() напрямую был причиной ошибки JVM. Рекомендация: Решение - использовать пакет java.lang.reflect и вызывать его таким способом:

• Класс c: Class.forName("javax.xml.rpc.ServiceFactory")
• Метод m: c.getMethod("newInstance", null)
• Сервис s: (Service)m.invoke(null, null)

См. документацию по Java-рефлексии, если вы вызываете методы с аргументами.

Использование оперативной памяти

На нашей тестовой машине, краткосрочные (10-минутные) тесты с более чем пятью пользователями вызывали ошибки из-за нехватки памяти, когда в график теста было включено ведение журнала по умолчанию. Следовательно, мы установили ведение журнала в состояние none (отсутствует), после того, как убедились, что всё работает правильно. Как мы описываем ниже в разделе Тесты и процедуры, для анализа нагрузки нам всё равно не потребовались функции ведения журнала Rational Performance Tester.

Выполнение с помощью командных файлов

Rational Performance Tester V 6 поддерживает выполнение с помощью командных файлов в Windows через плагин cmdlineexecute. Однако в Linux эта функция не работает. Ситуация изменится к концу 2006 - началу 2007 г, когда ожидается выход Rational Performance Tester версии 7.

Только администратор

Некоторые компоненты Rational Performance Tester работают неправильно, если вы их запускаете, войдя в систему пользователем без административных привилегий. Мы запускали Rational Performance Tester, войдя в систему то администратором (root), то обычным пользователем, и получили различные результаты. Иногда он работает, а иногда нет. Рекомендация: Всегда запускайте Rational Agent Controller, войдя в систему администратором.

Тесты и процедуры

Мы провели четыре различных теста, чтобы определить, соответствует ли Rational Performance Tester нашим требованиям.

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

Это был главный тест, который мы использовали для оценки потенциала Rational Performance Tester в качестве замены WPT в нашей среде. Нас больше всего интересовала возможность Rational Performance Tester производить нагрузку, сопоставимую с WPT. Нас также интересовали ресурсы, необходимые для тестовой машины, чтобы сделать это возможным.

Тест. С помощью инструмента записи в Rational Performance Tester и WPT мы создали тест, посещавший случайную страницу (Random page) книжного магазина zipSeries. Эта страница вызывает сервлет SetRandom для случайного выбора названия книги из списка книг, а затем моделирует процесс покупки. На странице Random page пользователь может указать, сколько книг выбрать, и сколько из них купить. Мы заставили каждый инструмент использовать Random page для поиска в полном списке названий, а затем для выбора одной случайной книги. SetRandom также размещает, по меньшей мере, одну покупку для каждого случайного поиска (указана покупка или нет). Следовательно, этот тест эффективно моделирует один случайный поиск и одну покупку, то есть две транзакции каждый раз.

Страница Random page автоматически закрывается после завершения сессии пользователя, что помогает освободить ресурсы WebSphere Application Server. Следовательно, результаты случайного вызова никогда в действительности не отображаются в Web-браузере, и мы используем Random page только для тестирования.

Записанные тесты были изменены таким образом, чтобы они передавали параметры непосредственно SetRandom, не посещая сначала страницу Random page по умолчанию. Это сокращает лишний HTTP-трафик. Единственные данные, которые возвращаются в программу stress - это страница выхода из системы.

WPT использует концепции клиентов и потоков , где клиент (пользователь по терминологии Rational Performance Tester) отвечает за начало записанного теста и посещение заранее указанной Web-страницы. Потоки клиентов отвечают за завершение моделирования, что означает посещение дополнительных записанных страниц во время теста. Rational Performance Tester также использует потоки, но конечные пользователи не могут контролировать их таким же образом. Это ещё одна причина, почему мы заставляли тест посещать лишь одну страницу во время моделирования, так как это может быть лучше с точки зрения сравнения. В записи WPT мы установили количество потоков на клиента 1 (один), но так как посещается только одна страница, это число не подходит.

Примечание:
Посещения осуществлялись непосредственно через порт WebSphere Application Server, пересылки через HTTP-сервер IBM не было.

Измерение: Хотя и Rational Performance Tester, и WPT обеспечивают статистику выполнения теста, мы использовали собственный механизм измерения их возможностей. Мы измеряли нагрузку количеством выполненных транзакций базы данных, а не посещёнными Web-страницами, и мы измеряли локальные ресурсы при помощи постоянно ведущегося журнала vmstat.

У нас есть программа, встроенная в WebSphere Application Server, которая сбрасывает все выполняемые WebSphere Application Server транзакции базы данных в файл. Со временем этот файл анализируется и передаётся нашей базе данных SLA. Мы называем это методом скребка (scraper). Первоначально у нас WebSphere Application Server напрямую обновлял базу данных SLA через JDBC, но мы обнаружили, что это значительно снижает производительность теста. Теперь мы проверяем базу данных SLA в конце выполнения теста, чтобы определить количество проведённых транзакций.

Процедура: В обоих программных пакетах мы смогли указать, сколько раз повторять тест, а также максимальное время его выполнения. Каждый тест безостановочно повторялся 10 минут, с максимум 10000 повторениями (мы специально выбрали количество, которое никогда не будет достигнуто с такими временными рамками). Весь процесс продолжался около часа для каждого продукта, так как мы запускали нагрузки для 1, 5, 10, 15, 20 и 25 пользователей для каждого. В то время как процесс тестирования для WPT полностью управлялся скриптом, выполнение с помощью командных файлов ещё не поддерживается в Linux-версии Rational Performance Tester. Рекомендация: Следовательно, вам, возможно, потребуется выполнить такие же шаги, какие выполняли мы, для запуска тестов:

1. Перезапустите ПО WebSphere Application Server при работе zipSeries.
2. Запустите обновление базы данных SLA, чтобы убедиться, что все предыдущие транзакции включены.
3. Получите и запишите общее количество транзакций от базы данных SLA перед тестом.
4. Начните журнал vmstat с двухсекундным интервалом на тестовой машине.
5. Запустите нагрузочный тест с X одновременных пользователей.
6. Снова запустите обновление базы данных SLA.
7. Снова получите общее количество транзакций от SLA после теста, а затем сравните его с общим количеством до теста.

Примечание:
Общее количество транзакций от базы данных SLA включает как транзакции при навигации (Browse), так и транзакции при покупке (Buy). Мы занесли эти цифры в таблицу, которую использовали позднее для анализа журналов vmstat.

Путь передачи данных. Рисунок 1 показывает, как работает сравнительный тест. Он начинается с тестовой машины (на которой работает Rational Performance Tester или WPT), получающей доступ к SetRandom в ПО zipSeries. Из базы данных Browse выбирается случайное название, а затем производится покупка с помощью базы данных Buy. Со временем базе данных SLA отправляется журнал scraper log, и статистика транзакций, в конце концов, оказывается на тестовой машине. Имейте в виду, что вне зависимости от нормального режима работы zipSeries, при тестировании вся коммуникация с базами данных осуществляется через JDBC, в том числе и покупки.

Рисунок 1. Как работает сравнительный тест

Rational Performance Tester: Случайный поиск по имени автора с помощью клиента Web-сервиса и функции Custom Code

Функция пула данных позволяет Rational Performance Tester тестировать случайные значения для ввода на Web-страницы во время работы теста. Это отличная функция, которой так не хватает WPT. Она позволяет клиенту выполнять рандомизацию, не перекладывая эту функцию на сервер, как в случае с SetRandom. Это может потенциально освободить ресурсы WebSphere Application Server, так как этот сервер не будет более отвечать за определение случайных имён. Как мы упомянули ранее, реализация пула данных Rational Performance Tester имела ограничения в нашей среде. К счастью, Rational Performance Tester имеет ещё одну функцию, Custom Code, которая позволяет пользователям разрабатывать собственные подпрограммы для введения данных в запрос к Web-странице. Мы создали два следующих теста как альтернативы пулам данных Rational Performance Tester.

Изначально идея была разработать пользовательский код, напрямую запрашивающий у базы данных Browse случайное имя автора. В этом случае мы могли бы выполнять Rational Performance Tester в течение очень долгого времени, моделируя множество поисков различных авторов. Однако это создало бы значительное количество издержек JDBC и дополнительную нагрузку на сервер базы данных. Следовательно, мы создали Web-сервис, кэширующий имена, полученные от Browse, и работающий на отдельном сервере WebSphere Application Server при помощи пула соединений JDBC. Затем мы разработали пользовательский код Rational Performance Tester, который работает как клиент для этого Web-сервиса.

Тестирование и измерение были аналогичными первому тесту, за тем исключением, что вместо записи посещения Random page, мы записывали посещение страницы Books page и выполняли поиск по автору. Это тип поиска возвращает все названия из базы данных Browse, связанные с этим автором. В Rational Performance Tester мы смогли указать, какие значения заменять из пользовательского кода в запросе к странице поиска. Имейте в виду, что он может производить только одну транзакцию базы данных через WebSphere Application Server, по сравнению с двумя в предыдущем тесте. Этот тест также не завершал сессию. Тем не менее, так как мы перезапускали WebSphere Application Server перед каждым выполнением теста, это не имеет большого значения.

Путь передачи данных. Рисунок 2 показывает, как работает тест Web-сервиса Rational Performance Tester. Он начинается, когда пользовательский код Rational Performance Tester запрашивает случайное имя автора у Web-сервиса, а потом ищет это имя на сайте zipSeries. Транзакции регистрируются в файле и, в конце концов, отправляются базе данных SLA, а затем тестовой машине.

Рисунок 2. Тест Web-сервиса

Rational Performance Tester: Случайный поиск по имени автора с помощью простого клиента socks

Хотя пользовательский код Web-сервис работал правильно как отдельный код в Rational Application Developer, нам потребовалось некоторое время, чтобы определить процесс, необходимый, чтобы заставить Rational Agent Controller включить J2EE-библиотеки правильно. Кроме того, для пользователей, у которых установлен только Rational Performance Tester, использование Web-сервиса непосредственно с пользовательским кодом не будет работающим решением.

Наконец, мы обнаружили, что установка нового соединения с Web-сервисом была медленной, так что мы должны были заново устанавливать соединение каждый раз, когда Rational Performance Tester требовалось новое имя автора. Не было очевидного способа поддержания постоянного соединения в пределах пользовательского кода. Поэтому мы разработали клиент-серверную пару TCP/IP-сокетов, которая будет работать как сервер-посредник (proxy) для Web-сервиса. В идеале сервер должен работать на той же машине, что и Web-сервис и постоянно поддерживать соединение с Web-сервисом. Клиент должен работать надёжно из Custom Code, так как базовые TCP/IP-сокеты включены в стандартные библиотеки J2SE. Эта процедура была точно такой же, как и в предыдущем тесте, хотя мы изменили пользовательский код для использования клиента proxy Web-сервиса.

Путь передачи данных. Рисунок 3 показывает, как работает тест proxy Web-сервиса Rational Performance Tester. Сначала функция Custom Code Rational Performance Tester запрашивает случайное имя автора у proxy Web-сервиса, который доставляет имя от Web-сервиса. По этому имени затем осуществляется поиск по сайту zipSeries. Транзакции регистрируются в файле и, в конце концов, отправляются SLA, а затем тестовой машине.

Рисунок 3. Тест proxy Web-сервиса

Rational Performance Tester: Оценка при длительной работе

В этом тесте мы запускали Rational Performance Tester на 19 часов с нагрузкой 30 пользователей, сравнивая процедуры 1 и 3. Этот длительный тест преследовал две цели: посмотреть, как машины, задействованные в тесте Rational Performance Tester, будут реагировать на длительную нагрузку, и определить, сколько процессорного времени экономится на сервере zipSeries, если функциональность случайных запросов была переложена на отдельную машину. Следовательно, для каждого теста мы регистрировали и локальные ресурсы, и ресурсы сервера.

Результаты тестов

Шесть приведённых ниже таблиц приводят полученные нами данные под следующими названиями колонок:

• Users обозначает количество клиентов, которое тестовое ПО запустило на фоне сервера WebSphere Application Server.
• Total Trans - количество транзакций, выполненных тестовой машиной за 10-минутное время выполнения (эта цифра показана в колонке Trans/Sec).
• Tot. Mem - максимальный объём используемой операционной системой памяти (и физическая память RAM, и своп) во время этой сессии.
• Max CPU Time - максимальный процент времени в секундах, в течение которых процессор использовался (исполняя и код ядра, и другой код, в том числе время ожидания ввода-вывода).
• Avg CPU Time - средний процент времени, в течение которых процессор использовался.

Примечание: Эта статистика была сгенерирована журналами vmstat с двухсекундным промежутком, которые мы вели в ходе тестов.

После завершения Теста 1, сравнения Rational Performance Tester и WPT, мы узнали большую новость о Rational Performance Tester: Хотя он и загружает ресурсы очень сильно, он значительно быстрее WPT. В лучшем случае (минимальная нагрузка), Rational Performance Tester обрабатывал на 236% больше транзакций, чем WPT. В худшем случае (максимальная нагрузка), Rational Performance Tester всё равно мог обрабатывать на 30% больше транзакций, чем WPT за тот же период времени.

Рисунок 4. Таблица 1: тест 1, результаты WPT

Рисунок 5. Таблица 2: тест 1, результаты Rational Performance Tester

Требования к ресурсам так же важны, как и различие в скорости. В качестве способа объективной оценки работы требовательного к ресурсам Rational Performance Tester, мы использовали такой же подход (10 минут с двухсекундным промежутком), когда Rational Performance Tester не работал. Таблица 3 показывает, что ситуация с ресурсами была как после перезагрузки, загрузки X11 и запуска Rational Agent Controller.

Рисунок 6. Таблица 3: системные ресурсы при неработающем Performance Tester (контрольный тест)

Когда тест не выполняется, активность незначительная. Ожидайте, что Rational Performance Tester будет использовать несколько сот мегабайт оперативной памяти в холостом режиме. К счастью, использование памяти возрастает незначительно при большой нагрузке, если только не включен режим регистрации всей информации.

Рекомендация: Мы предлагаем использовать, по меньшей мере, одну выделенную машину для выполнения тестов на время полезной работы. В нашей среде у нас уже были такие машины для тестирования WPT, и мы планируем их использовать в будущем для Rational Performance Tester. Мощь Rational Performance Tester в быстром выполнении тестов является явным преимуществом для любого специалиста, серьёзно занимающегося тестированием целостности сайта.

Оставшиеся тесты сравнивали различные стратегии работы Rational Performance Tester. Мы также запускали их под нагрузкой в 30 пользователей, чтобы определить, продолжает ли расти производительность с увеличением числа пользователей. В тестах 2 и 3 мы обнаружили, что 25 пользователей является оптимальной нагрузкой для нашего оборудования.

Тест 2 измерял производительность Rational Performance Tester при поиске случайных имён авторов, доставляемых через Web-сервис. Производительность была более-менее постоянной, но, в целом, самой низкой из всех выполненных нами тестов, а памяти при этом использовалось больше всего.

Рисунок 7. Таблица 4: результаты теста 2

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

Примечание:
Следует подчеркнуть, что узкое место является результатом того, как мы реализовали решение в Custom Code; Следовательно, это проблема не только Rational Performance Tester.

При использовании функции Custom Code, вы должны особенно позаботиться о применении эффективных методов, которые не увеличат чрезмерно рабочую нагрузку на тестовый сервер. Однако в случае использования Web-сервиса напрямую, для нас не было очевидно, как сделать наш пользовательский код более эффективным. Вот почему мы посчитали, что оба теста, 2 и 3, являются ценными процедурами, и включили их в этот отчёт.

Тест 3 походил на тест 2 в том, что он использовал Web-сервис для получения случайных имён, но в нём использовался сервер-посредник (proxy) между Rational Performance Tester и Web-сервисом для постоянного поддержания соединения с Web-сервисом. В большинстве случаев, результаты теста 3 был почти в 2 раза выше, чем результаты теста 2.

Рисунок 8. Таблица 5: результаты теста 3

В связи с тем, что тест 1 и тест 3 работают по-разному, мы не смогли провести их корректное сравнение. Тем не менее, вот интересное наблюдение: тест 1 вызывает SetRandom на WebSphere Application Server. SetRandom преднамеренно выполняет две транзакции почти одновременно в пределах одной подпрограммы. Следовательно, для теста 1 Rational Performance Tester выполняет одну элементарную операцию, чтобы получить две транзакции, а в тесте 3, он выполняет одну элементарную операцию, чтобы получить одну транзакцию. Если мы удваивали транзакции, получаемые Rational Performance Tester в тесте 3, мы замечали, что результаты были сопоставимы с результатами теста 1, а при небольших нагрузках всё работало гораздо лучше. Рекомендация: Следовательно, мы полагаем, что если вам нужна неограниченная рандомизация для конечного пользователя, использование proxy для кэширования Web-сервиса - это ваш путь.

На рисунке 9 показаны основные результаты тестов 1 - 3.

• Test 1 показывает результаты Rational Performance Tester для первого теста, а WPT показывает результаты WPT для первого теста.
• Test 2 и Test 3 - результаты Rational Performance Tester для соответствующих тестов.

Рисунок 9. Сравнение уровней транзакций WPT и Rational Performance Tester

Таблица 4 снова показывает, насколько быстр Rational Performance Tester по сравнению с WPT. Даже тесты Web-сервиса Rational Performance Tester были быстрее WPT при небольших нагрузках, когда в качестве лучшего подхода применялся метод proxy Web-сервиса теста 3.

В тесте 4 мы хотели определить, сколько процессорного времени освобождается у сервера приложений, если функциональность случайных имён перекладывается на тестовую машину. Мы обнаружили, что в среднем время использования процессора сервера zipSeries снизилось примерно на 15%, когда он не занимался рандомизацией. Мы были очень довольны, что Rational Performance Tester мог работать длительные промежутки времени без всяких проблем. Результаты показаны в таблице 6, где test обозначает статистику тестовой машины с Rational Performance Tester, а zip - статистику машины, на которой работал книжный магазин zipSeries.

Рисунок 10. Таблица 6: результаты теста 4

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

Выводы и планы на будущее

В целом, возможности Rational Performance Tester произвели на нас большое впечатление. Хотя он и использует больше локальных ресурсов, чем WPT, он может выполнять больше транзакций за то же время. Функция Custom Code была очень полезной для снятия части нагрузки с машины, на которой работал WebSphere Application Server. Способность выполнять различные тесты одновременно позволит нам объединить процесс тестирования. Так как Rational Agent Controller может распространять тесты по многим машинам, нам будет легче анализировать влияние на трафик из различных мест. Следовательно, Rational Performance Tester содержит почти все функции, которые нам нравятся в WPT, плюс несколько мощных дополнительных возможностей. Хотя инсталляция заняла время, прошла она просто. После инсталляции Rational Performance Tester не требуется дополнительная настройка, кроме установки обновлений. Графический интерфейс пользователя позволяет быстро освоить основные функции и возможности.

Выражая наше удовлетворение Rational Performance Tester, мы планируем использовать его для непрерывного тестирования. Мы модифицируем метод SetRandom в ПО zipSeries для наилучшего использования Web-сервиса случайных имён. Сам Web-сервис нужно будет улучшить, если мы решим расширить его таким образом, чтобы он выполнял всю функциональность, связанную с навигацией. Мы рассмотрим возможность использования основанного на DADX Web-сервиса. Как мы уже упоминали, Rational Performance Tester позволит нам объединить и организовать некоторые виды тестирования, а когда будет сделана поддержка плагина cmdlineexecute для Linux, мы сможем выполнить миграцию некоторых наших тестовых скриптов, основанных на WPT.