Существенное снижение производительности после перехода на AX 2009 с Axapta 3.0

[BOAL]

Спасибо всем за объяснения, покопал, поразбирался - теперь больше в теме.
На деле смутил стереотип, что со времен ах 2.5-3.0 тесты на локале (ноуте, ПК) проходили сильно медленнее, чем на боевом серве.
Но теперь бытовые ноуты имею процы тех самых серверов и в однопользовательском режиме работают быстрее (парадокс, который и вызвал непонимание), чем на боевом дорогущем сервере.
Так как в один поток серверное одно ядро вполне сопоставимо (а то и ниже по частоте) проца бытового ПК.

Масштабирование предполагалось же не только от увеличения числа пользователей, но и числа данных.
Раньше это прокатывало, тк сервера становились мощнее (частоты и кэш одного ядра). Теперь прогресс встал колом - увеличивают ядра.
Если в БД что-то долгое считается 1 час, то когда данных будет х2, будет условно считать 2ч. И железкой это не лечится, тк ничего не даст.
Нужно предварительно переписать логику на многопоточность.
Ну или в данной ситуации проблема так остро (в х2 раза) не встанет из-за более умного SQLа, который заюзает ядра все подряд, даже на 1 селект (надеюсь это так?).

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

Вот скажите мне, кто в теме, модные облачные вычисления будет так же работать?
Будет, скажем, в облаке древний 386 проц и он выпадет кому-то в помощь как один поток или как часть потока совместно с другими процами? За счет чего будет работать облако, за счет софта оболочки (облока) или спецом написанных програм для работы в этом облаке?
Так как АХ2009 при таком АОС в облаке запускать категорически нельзя, если ему хаотично будет выбираться одно ядно произвольного (по мощности) проца.
Есть же куча старого софта который не знает о многоядерности. И внутри ОС Виндовс этот софт занимает все ядра по 100%, а если в диспетчере выделить только одно, то сразу видны тормоза. Значит как это это работает и без переписывания на потоки, может не столь эффективно, как заложенное в коде деление, но работает.
Соотв. по идее нужно аналогично дать АОСу виртуальные ядра, из кучи реальных, что и даст требуемый прирос именно аппаратно, а без тюнинга кода.