axperf: Multiple new Benchmarks released: Microsoft Dynamics AX 2012 R2 Multiple Retail Workloads, Microsoft Dynamics AX 2012 R3 Financial Benchmark, Microsoft Dynamics AX 2012 R3 Day in the Life Benchmark for Retail and Distribution

[Blog bot]

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

We are happy to announce that the following benchmarks will be available, just in time for Tech conference 2015. We have published both summary and detail documents for each benchmark. Microsoft Dynamics AX 2012 R2 Benchmark for Multiple Retail Workloads...(read more)

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

[gl00mie]

Очень познавательные тесты производительности, наконец-то в них фигурирует AX 2012 R3. Для меня лично интересным оказалось сравнение того, какую нагрузку на СУБД и систему хранения данных (СХД) создает AX 2012 RTM в тесте Day in the Life от апреля 2012-го и AX 2012 R3 в тесте Day in the Life for Retail and Distribution от ноября 2014-го. Если я не ошибся в расчетах, RTM-версия на одну обрабатываемую строку документа требует в пике около 40 IOPS, в то время как R3 - меньше 20 IOPS. Весьма вероятно, это связано с изменением способа хранения в БД иерархий таблиц и соответствующим упрощением запросов к СУБД.
"Усредненная наихудшая" величина IOPS на обработку одной строки документа - важный параметр при расчете требуемой производительности СХД на проектах внедрения Аксапты, поэтому отрадно, что данная величина ощутимо снижается с выходом новых версий системы.

[imir]

Цитата:

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

связано с изменением способа хранения в БД иерархий таблиц и соответствующим упрощением запросов к СУБД

Хм.. то, что вся иерархия теперь хранится в одной мега-разряженной таблице - это улучшение?

Мне кажется они просто прошлись по узким местам и понатыкали global cashe куда можно.

[gl00mie]

Да, по-моему, одна таблица, где "неактуальные" поля имеют значение NULL, и простой select по ней - это улучшение по сравнению с несколькими разными таблицами и кучей outer join'ов по ним "наугад". Может, в новых версиях и понатыкали global cache, может, даже оптимизировали global cache по аналогии с тем, как в R3 оптимизировали SysExtention framework. Но факт остается фактом: система становится более производительной и масштабируемой по сравнению с 2012 RTM.

[Logger]

Класная тема.
Интересно все же докопаться, что было ключевым фактором ускорения.

Предположу, что тупо эффективнее стал использоваться кеш БД.

[imir]

Цитата:

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

простой select по ней - это улучшение по сравнению с несколькими разными таблицами и кучей outer join'ов по ним "наугад".

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