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

[Blog bot]

Источник: http://blogs.msdn.com/aeremenk/archi...2/8149436.aspx
==============


Тестирование производительности в 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, которые поставляются отдельно.


Запустил предоставляемый файл и распаковал все в 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

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

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

Ага, ругается, надо существующие данные в шаблоны экспортировать, как минимум список клиентов не совпадает :)
Создал группы определения для экспорта/импорта типа "Excel" и экспортировал реальные данные компании в документы каталога Datasource.
Попробую запустить тест. Копирую SalesAndDistribution.loadtest в Microsoft.Dynamics.Benchmark.TestProject, хотя ... можно было просто пути в cmd подправить.
Ок, поправил, пробую опять...
За активностью можно следить как со стороны AX:

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

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

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

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

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

Резюме:

• Внимательно анализируйте установки и пути для копирования и запуска скриптов;
• Если используете стандартные скрипты - установите все в каталог 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.


Источник: http://blogs.msdn.com/aeremenk/archi...2/8149436.aspx