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

[propeller]

Хотели бы сравнить две инсталляции AX 2009 (RU7), одна на физ. серверах, другая на виртуальных (БД и приложение одинаковые).
Посоветуйте, пожалуйста, какой-нибудь job или операцию, которая бы с помощью таймера показала время выполнения в разных инсталляциях.
Спасибо.

[Vadik]

Обновление перекрестных ссылок ?

[BOAL]

Тогда уж закрытие склада, тк перекрестные ссылки это не работа с реальными данными.
Но разница в два раза, конечно, тоже показательно.

А так, берем джоб (лучше класс, чтоб тестить клиент-сервер правильно)
запоминаем время до и потом после
Крутим цикл на 1000-100000, в нем уже от фантазии.
Можно тестить только проц, тогда без обращения к БД

Или селектить что-то (причем, чем больше записей в таблице, тем заметнее будет)

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

Я уже писал, что АХ юзает один поток на вычисление, а это 1 ядро (или пол-ядра, тк Гипертрейдинг тут зло), а ядро сервера работает +- на той же частоте, что нормальный ПК или крутой ноут.
У меня отчет на ноует и боевом севре строился почти одинаковое время.

А вот колво ОЗУ может влиять, и сиквел иначе использует ресурс.

Поэтому смотрим еще на
1. % загруза процов и ядер
2. загруз ХДД на АОС и БД серверах

И еще запустить потом этот же джоб параллельно 4-5 раза, и тоже посмотреть (тут сервер с кучей ядер выдаст тоже, что и первый раз, а вот без кучи ядер, будет черепашка )

Ну и доку почтитать по средствам бенчмарка АХ, есть там такая фича в меню разработки - на форуме посерчить.

[gl00mie]

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

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

Под все это были подготовлены шапки пустых заказов, файлы с данными для создания строк и написан небольшой класс, который все это выполняет. Дальше уже дело техники: можно скриптом дергать этот класс через Business Connector или, скажем, генерить xml-файл для SysAutoRun, дающий аналогичный эффект при использовании виндового клиента Аксапты. Ну и запустить одновременно ндцать десятков сессий, выполняющих все это в цикле. В моем, опять же, случае одна итерация занимала ощутимое время, так что хронометраж велся по обычным часам - был лишь настроен сбор разного рода счетчиков производительности, чтобы потом можно было детально поразбираться, где именно было узкое место.
Пожалуй, чем точнее удастся воспроизвести свои самые типовые (ну и при этом достаточно тяжелые) операции, тем точнее получится оценка падения производительности из-за виртуализации. Если же увлечься синтетическими оторванными от жизни тестами, можно получить весьма искаженные результаты.