axperf: “Day in the Life Benchmark” available for Download on PartnerSource and CustomerSource.

[Blog bot]

Источник: http://blogs.msdn.com/b/axperf/archi...mersource.aspx
==============

As of now the “Day in the Life Benchmark” for Microsoft Dynamics AX 2012 is available for download. It showcases the immense amount of performance and scalability improvements which have gone into Microsoft Dynamics AX 2012. Some of the...(read more)

Источник: http://blogs.msdn.com/b/axperf/archi...mersource.aspx

[gl00mie]

Сильно: 5135 конкурентных пользователей, база 1.8 Тб (не считая логов), правда, уже не стали заморачиваться со сжатием данных, как для 2009-й. Ну и сервер БД такой нехилый: 4x12 2.2 ГГц AMD Opteron (всего 48 ядер), 256 Гб памяти, хранилище на 50 дисках... Для сравнения, в Day In the Life для AX 2009 было 2250 конкурентных пользователей, сервер БД работал на 8х4 2.3 ГГц AMD Opteron (32 ядра), 128 Гб памяти, хранилище на 96 дисках.

PS. Очень занятно, что в этом тесте описывают, какие оптимизации делались в схеме БД и в коде - для аналогичного теста на 2009-й такой информации не было. Практически во всех добавленных для оптимизации индексах поле DataAreaId задвинуто на последние-предпоследние места.

PPS. Еще интересно: войдут ли сделанные оптимизации в стандартное приложение?

[Mykola Galak]

Цитата:

Сообщение от gl00mie

Практически во всех добавленных для оптимизации индексах поле DataAreaId задвинуто на последние-предпоследние места.

В тесте 90% данных приходятся на одну компанию. Логично что DataAreaId сдвинули с первой позиции для повышения селективности индекса.

[fed]

Меня в тестах, которые команда Сринивасана проводит, смущает тот факт, что тестируется все это не живыми пользователями, а скриптами Visual Studio, которые через Business Connector вызвают какие-то классы, которые эммулируют работу пользователя. С одной стороны - конечно это разумное приближение к реальной производительности. С другой стороны - как бы вы отнеслись, если в конце рекламы средства для повышения мужской потенции, вы бы увидели приписку маленькими буквами: "Клиническое тестирование лекарственного средства производилось с использованием резиновых женщин"...

[Mykola Galak]

Подобные тесты напоминают синтетические тесты производительности железа, типа PC Mark, где что-то меряется в попугаях .
По моему субъективному мнению, клиент стал заметно медленнее. По отзывчивости он примерно сравнялся с порталом. В тоже время, очень нравится трюк с всплывающим окном "Processing" когда клиент занимается обработкой в фоновом режиме. В предыдущих версиях клиент просто "бледнел" в таких случаях, а в АХ2012 пользователь может рассматривать данные. Создается впечатление что клиент все еще жив, но работать в нем все-равно нельзя.
Интересно послушать отзывы кто уже внедрился или потестировал под нагрузкой с реальными пользователями.

[gl00mie]

Цитата:

Сообщение от fed

Меня в тестах, которые команда Сринивасана проводит, смущает тот факт, что тестируется все это не живыми пользователями, а скриптами Visual Studio, которые через Business Connector вызвают какие-то классы, которые эммулируют работу пользователя. С одной стороны - конечно это разумное приближение к реальной производительности.

Интересно, а какие, собственно, есть альтернативы? Те же методики гибкой разработки делают упор на автоматизированном тестировании, в т.ч. регрессионном. Я лично уверен, что до публикации финальных результатов тест прогонялся не один десяток раз - ведь не озарением же объясняется куча новых индексов, прикрученных для оптимизации, и некоторые изменения в коде, сделанные с той же целью. И как это все провернуть на живых пользователях? Как научить 5000+ человек быстро-быстро выполнять однотипные операции и проделывать это несколько десятков раз подряд в течение нескольких дней, синхронно, на пределе человеческих возможностей? Утопия...
Мне лично доводилось проводить автоматизированное тестирование производительности на основе некоторого очень упрощенного сценария поведения пользователя (создание и обработка заказа на продажу - с учетом кучи промежуточных специфических этапов), когда встал вопрос о том, потянет ли система, если "вот прям щас" подключить условной 50-80 новых пользователей. Да, это было утрировано, да, ни один живой пользователь не пострадал, но результаты дали понимание того, 1) потянет ли, 2) где примерно в системе "узкое место" (СУБД "курила бамбук", тестовый АОС был загружен под самое "не балуйся"). Это лучше, чем ничего, потому что 50-80 настоящих пользователей мне бы никто на 1-2 дня чисто "для теста" никогда бы не выделил, а если бы и выделили, я бы застрелился прежде, чем объяснил им всем, что именно надо делать.

Цитата:

Сообщение от fed

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

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

[fed]

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

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

Создается ощущение что любопытное, с технической точки зрения, нагрузочное тестирование превратили в очередной маркетинговый высер. И теперь тупые маркетологи и сейлы будут при продажах с умным видом говорить про 5200 пользователей...

P.S. Кстати характерно, что результаты тестирования не выложены в открытый доступ. Ведь если бы методика тестирования была безупречной и подкопаться было бы не к чему, можно было бы их выложить в общедоступное место, на зло конкурентам, правда ведь ?

[George Nordic]

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

Вся тонкость - именно в исключительных ситуациях, а не как 5200 виртуальных обезьян колбасят войну и мирзаказы - отгрузки. Если бы хотя бы сотня из них разбиралась с сопоставлением и платежами, и еще штук 50 сторнировали и проводили заново, да еще и склад бы периодически пересчитывался... А так - имеем очередного коня в вакууме. Но лучше, чем ничего: по крайней мере, понятно, что на 5 000 юзеров оно работает. Возможно, где-нибудь в мире намечается еще одна чудо-продажа на 5+к юзеров, и ее необходимо обосновать. Поэтому и результаты закрыты.

С Уважением,
Георгий

[Mykola Galak]

Цитата:

Сообщение от gl00mie

Интересно, а какие, собственно, есть альтернативы?

Как вариант взять живую инсталяцию, например сити оф Редмонд, который в кейс стади фигурирует, и провести тесты на ней. Тесты - несколько сценариев из повседневной жизни пользователей, закрытие месяца, года. Чтобы порадовать маркетологов, можно видео сделать с секундомером в углу и показателями загрузки системы при выполнении операций в системе, ну и с улыбающимися пользователями конечно

[Vadik]

Цитата:

Сообщение от fed

Создается ощущение что любопытное, с технической точки зрения, нагрузочное тестирование превратили в очередной маркетинговый высер. И теперь тупые маркетологи и сейлы будут при продажах с умным видом говорить про 5200 пользователей

Это синтетический тест - не больше и не меньше. Что с его результатами будут делать маркетологи - это их личное дело. По мне - взята некая часто используемая операция в системе и заскриптовано ее выполнение множенством клиентов (не думаю что тот же SAP SD что-то принципиально иное делает). Показано что ядро (в данном контексте - AOS + разноска по GL-AR-Inventory) масштабируется до 5200 виртуально-сферических сейлов постящих инвойсы. Очевидно, что нагрузка смоделирована с большой погрешностью и накладные расходы от дополнительных запросов из UI могли бы свести это к скажем 3000 живых пользователей (если бы можно было организовать такое тестирование). Очевидно, что живые сейлы тоже по одному заказу в минуту не инвойсят и этих 5200 "попугаев" можно при желании экстраполировать хоть до 10000 "живых" периодически что-то постящих (оставим это на совести маркетологов). Тем не менее, цифры хорошие и выше чем выдавала прошлая версия. Что не так ?

Цитата:

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

Ну привет... А смысл ? И где его (железо 2009 года) брать? И как на нем запускать 64-битный AOS к примеру ? И зачем тестировать на заведомо устаревшем и недоступном оборудовании? Смысл ведь не в том чтобы запустить на идентичном железе, а в том чтобы запуститься на оборудовании сопоставимой стоимости

Цитата:

P.S. Кстати характерно, что результаты тестирования не выложены в открытый доступ. Ведь если бы методика тестирования была безупречной и подкопаться было бы не к чему, можно было бы их выложить в общедоступное место, на зло конкурентам, правда ведь ?

Ну а это уже конспирология какая-то.. Потерпи немного, сейчас маркетологи над документом поработают и наверняка обнародуют вторую редакцию

[Mykola Galak]

Цитата:

Сообщение от Vadik

Смысл ведь не в том чтобы запустить на идентичном железе, а в том чтобы запуститься на оборудовании сопоставимой стоимости

Цитата:

Сообщение от Vadik

Тем не менее, цифры хорошие и выше чем выдавала прошлая версия. Что не так ?

А как показать, что цифры выше за счет системы, а не только благодаря железу? Серверок в тесте АХ2012 где-то на 50% помощнее будет чем сервер в аналогичном тесте АХ2009. АХ2012 тест - 5135 конкурентных пользователей, АХ2009 - 2250.
Маркетологи говорят: "In fact, we've clocked Microsoft Dynamics AX 2012 at as much as 20 times faster than Microsoft Dynamics AX 2009 for some tasks!" http://blogs.msdn.com/b/dax/archive/...-20-times.aspx

[trud]

Цитата:

Сообщение от gl00mie

Интересно, а какие, собственно, есть альтернативы? Те же методики гибкой разработки делают упор на автоматизированном тестировании, в т.ч. регрессионном. . И как это все провернуть на живых пользователях? Как научить 5000+ человек быстро-быстро выполнять однотипные операции и проделывать это несколько десятков раз подряд в течение нескольких дней, синхронно, на пределе человеческих возможностей? Утопия...

А вот это как раз и можно было сделать старым модулем benchmark. в одном из режимов как раз и открывались реальные формы и нажимались реальные кнопки
То что есть сейчас это очень сильное упрощение, по сути никак не учитывается интерфейс, на котором могут быть дисплей методы и прочии вещи
Хотя этот модуль отлично поднимается с трешки

[S.Kuskov]

Цитата:

Сообщение от Mykola Galak

А как показать, что цифры выше за счет системы, а не только благодаря железу? Серверок в тесте АХ2012 где-то на 50% помощнее будет чем сервер в аналогичном тесте АХ2009

Можно провести сравнительное тестировани АХ2009 на новом оборудовании

[trud]

Цитата:

Сообщение от S.Kuskov

Можно провести сравнительное тестировани АХ2009 на новом оборудовании

А смысл. По моему тут весь смысл что 2012 на серваке к примеру за 10.000 тыс долларов работает быстрее чем 2009 работала на аналогичном по стоимости сервере. понятно то что со временем оборудование растет в скорости и падает в стоимости

[Mykola Galak]

Цитата:

Сообщение от trud

А смысл. По моему тут весь смысл что 2012 на серваке к примеру за 10.000 тыс долларов работает быстрее чем 2009 работала на аналогичном по стоимости сервере. понятно то что со временем оборудование растет в скорости и падает в стоимости

Я вижу смысл в объективности утверждения что АХ2012 производительней АХ2009. Через год на рынке можно будет купить сервер за 10к более производительный чем можно купить сейчас за теже 10к, но АХ то от этого производительней не станет. Звучит как попытка прикрыться прогрессом железа.

[Vadik]

Цитата:

Сообщение от Mykola Galak

Через год на рынке можно будет купить сервер за 10к более производительный чем можно купить сейчас за теже 10к, но АХ то от этого производительней не станет

Обосновывать как-то будете? А то голословно немного на фоне удвоения количества ASU

[Logger]

Цитата:

Сообщение от fed

Я прекрасно понимаю, зачем нужно автоматизированное тестирование, в том числе и нагрузочное. Просто не очень понятно, какой практический смысл в публикации его результатов ? Помочь клиентам и партнерам с сайзингом ? Ну так во первых - в реальности инстолляции таких размеров вообще редко случаются, а если и случаются то в силу специфики бизнеса нарезаются на несколько более мелких.

Совсем необязательно нарезать на несколько более мелких. Мне кажется что таким образом сопровождение системы резко удорожается. Удобнее не нарезать на кучу базенок, а делать все в одной базе и в одном приложении. Конечно, при условии что решены проблемы с производительностью и с лицензированием все честно.

[fed]

Цитата:

Сообщение от Logger

Совсем необязательно нарезать на несколько более мелких. Мне кажется что таким образом сопровождение системы резко удорожается. Удобнее не нарезать на кучу базенок, а делать все в одной базе и в одном приложении. Конечно, при условии что решены проблемы с производительностью и с лицензированием все честно.

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

[Logger]

Согласен, что выгода получается только если удастся сделать унификацию бизнеса.

Кто смог, тот молодец.

[gl00mie]

Цитата:

Сообщение от fed

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

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