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

[fed]

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

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

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

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

[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

[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 пользователей смогли удовлетвориться функциональностью одной инстолляции.

[gl00mie]

Цитата:

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

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

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

[fed]

Цитата:

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

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

Если у нас порядка 5000 клиентов, то это значит что у нас порядка 13-15 бизнесов. Чтобы спроектировать нормальное целостное приложение, надо все эти бизнесы одновременно обследовать, одновременно спроектировать непротиворечивые доработки системы, однвременно запустить и тп. Что-то мне сложно представить команду консультантов и разработчиков, которые смогут все это сделать.
Можно конечно запускать эти бизнесы последовательно (что обычно и делается), но при таком раскладе очень может случиться что при попытке запихать в единое приложение 4ый бизнес-юнит, выяснится что то что напрограммили для 1ого и 2ого бизнес-юнитов в принципе не совместимо с тем что надо сделать для 4ого. В такой ситуации, несколько приложений может оказаться меньшим злом...

[belugin]

Цитата:

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

не совместимо с тем что надо сделать для 4ого.

А не возможен ли такой же принцип как сейчас со странами - параметр для включения функциональности того или иного бизнес-юнита в зависимости от компании.

[fed]

Цитата:

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

А не возможен ли такой же принцип как сейчас со странами - параметр для включения функциональности того или иного бизнес-юнита в зависимости от компании.

Возможен. Только ты вспомни, сколько времени и сил микрософт потратил (и еще потратит) на интеграцию всего этого зоопарка в единый слой. Есть ли у партнера или клиента бросить столько ресурсов на интеграцию результатов работы разных команд ради одного проекта ? (Пусть даже и большого).
Ну то есть - я не призываю вообще все бизнес-юниты и юрлица внедрять на отдельных инстолляциях. Всегда лучше постараться хотя бы часть из них соединить в одно приложение. Но я очень сомневаюсь, что при 5000 пользователях это возможно. При 1200-1500 пользователей - могу поверить; При 2000 - несколько сомневаюсь; При 5000 - никогда не поверю...