Condividi tramite

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

  • Articolo

Тестирование производительности в DAX 3.0 в основном заключалось в использовании внутреннего модуля Benchmark (BM). У него были достоинства, были и недостатки.

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

Расширение данного модуля требовало некоторых усилий, поскольку идеологически он был неким 'чужеродным' элементом в структуре модулей. С другой стороны, разобравшись с BM, можно было достаточно хорошо понять как работает Microsoft Dynamics AX 3.0 с точки зрения дизайна отдельных модулей.

 

В версии 4 изменилась схема имитаций действий пользователей, теперь запуск объектов Microsoft Dynamics AX выполняется из внешней среды с помощью средств Visual Studio (агент и котроллер) и Microsoft Dynamics AX Business Connector (COM и .NET).  Этим достигается определенный уровень универсализма, когда с помощью утилиты и Business Connector можно тестировать как объекты Microsoft Dynamics AX, так и сценарии работы с AIF (например, с BizTalk) или производительность веб-интерфейсов (Корпоративного Портала, например). 

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

Агенты через Business Connector (COM или .NET, в зависимости от настройки контекста) запускают объекты Microsoft Dynamics AX согласно сценарию.

 

Естественно, запустить выполнение формы или другого интерактивного объекта сложно, приходится эмулировать (повторять) поведение формы в других элементах Microsoft Dynamics AX, либо в коде Visual Studio.

Вообще-то, в BM версии DAX 3.0 в так называемом режиме 'Display independent' тоже запускались специальные классы, в которых эмулировалось поведение форм. Суффикс 'Batch' использовался для классов не интерактивного запуска, 'Display' - для запуска классов с формами и диалогами.

Строго говоря, вынос активных действий с интерактивных элементов (формы и диалоги) наметился в DAX 2.5 и получил развитие и для стандартной версии. Примерами могут служить классы поддержки форм журналов, например JournalFormTable и связанные с ним. Также начался вынос методов с форм на источники данных и таблицы.

 

Итак, новая утилита версии 4.0. 

Поскольку в стандартной поставке есть примеры для процесса разноски заказов на продажу (Sales Orders, SO), попробуем его настроить и запустить. Причем запустить 'малой кровью', не сильно вдаваясь в детали и по-минимуму изменяя настройки и код. 

Установил Visual Studio Team Suite (VSTS) как описано в документации.

Для работы понадобится еще Team Test Load Agent Controller и Team Test Load Agent, которые поставляются отдельно.

image

 

Запустил предоставляемый файл и распаковал все в C:\Benchmark.

Скопировал из каталога SalesAndDistribution файлы VSTestHost.exe.config в %Program Files%\Microsoft Visual Studio 8\Common7\IDE и QTAgent.exe.config в %Program Files%\Microsoft Visual Studio 2005 Team Test Load Agent\LoadTest.

Открыл каталог \bin и настроил все запускаемые файлы cmd на пути и сервера, которые есть у меня.

 

Открыл проект Benchmark.sln и пошел по шагам, описанным в 'Microsoft Dynamics AX Benchmark Toolkit Installation.doc':

  • Нажал  Build\Build the Solution (release).
  • Модифицировал setenv.cmd.
  • Отредактировал файлы настроек в \SalesAndDistribution

image 

  • Несмотря на то, что все запускается на одном и том же компьютере, настроил агента и контоллер, как удаленные.
  • Открыл Visual Studio 2005 Command Prompt.
  • Запустил deploy.cmd. 

image

  • Запустил runtest.cmd.

image

Ага, ругается, надо существующие данные в шаблоны экспортировать, как минимум список клиентов не совпадает :)

Создал группы определения для экспорта/импорта типа "Excel" и экспортировал реальные данные компании в документы каталога Datasource.

Попробую запустить тест. Копирую SalesAndDistribution.loadtest в Microsoft.Dynamics.Benchmark.TestProject, хотя ... можно было просто пути в cmd подправить.

Ок, поправил, пробую опять... 

За активностью можно следить как со стороны AX:

image

так и со стороны Visual Studio:

image

Ух, что-то выполнилось!

 image

Пойду смотреть логи.

В каталоге Results (в моем случае - C:\Results) можно найти текстовый файл LoadTest.log, описывающий что же собственно запускалось:

image

В каталоге Bin\Results (в моем случае - C:\Benchmark\Bin\Results) можно найти файл с расширением trx, который содержит значения счетчиков, настроенных для теста. Открыть его можно и в Visual Studio:

image

Хм, машинка слаба, загрузка процессоров слишком большая. Надо искать другой сервер? :)

 

Резюме:

  • Внимательно анализируйте установки и пути для копирования и запуска скриптов;
  • Если используете стандартные скрипты - установите все в каталог Benchmark;
  • Помните, что для запуска тестирования необходимо дополнительно установить Visual Studio Team Test Load Agent;
  • Генерация случайного выбора из справочников требует подготовленных данных - значений ключей ("E"+ числовое значение, преобразованное в строку);
  • Для работы можно использовать VSTS 2008 c Load Agent, если нет пробной версии VSTS 2005.

 

Теперь немного о самом модуле BM в DAX 4.

Часто слышу: "Как его использовать, он же бета?".  Данный модуль бета был оставлен для того, чтобы собрать как можно больше отзывов; бета стабильна и используется партнерами. Документация есть, хотя немного путанная. Судя по всему, BM в ближайшее время останется бетой.

Собственно, в DAX 3.0 BM был тоже своего рода вечной бетой, но вполне работоспособной. Более того, тестирование производительности не относится к модулям бизнес-процессов, сценарии (и, как правило, код) необходимо все равно изменять для модификаций или локализации.

Если Вы не собираетесь использовать BM даже в отдаленном будущем, имеет смысл прочитать его документацию, чтобы узнать побольше о Microsoft Dynamics AX Object Wrapper (о нем -  в следующей статье). Это может сильно облегчить переход к программированию в двух средах: AX и Visual Studio, поскольку интеграция становится все теснее... 

 

Данная статья подготовлена с помощью Windows Live Writer .