Microsoft Dynamics AX 4.0: Результаты тестирования производительности

[Lazy_Tiger]

А кстати, я НЕ ВЕРЮ что БД была перенесена с SQL2000 на SQL2005 as is. Не верю что не проводилась дополнительная оптимизация. Ибо мой результат на двух проектах - катастрофическое падение производительности. В РАЗЫ. И только после доплнительных шаманских действий по оптимизации индексов, по сбору доп. статистики и т.д. я получил обещанные 25-30% прироста. Так что это лож, п...ж и провокация

А еще я не верю в миф про разноску заказа до счет-фактуры в 5 тыс строк за 5 и даже 10 минут. Тем более не верю в то, что у кого то это могут сделать 20 пользователей одновременно

[mazzy]

Цитата:

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

И только после доплнительных шаманских действий по оптимизации индексов, по сбору доп. статистики и т.д. я получил обещанные 25-30% прироста. Так что это лож, п...ж и провокация

http://axapta.mazzy.ru/lib/axapta_benchmark_2005/
Пересчет статистики не шаманское действие.
Или я что-то не понимаю.

Цитата:

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

А еще я не верю в миф про разноску заказа до счет-фактуры в 5 тыс строк за 5 и даже 10 минут. Тем более не верю в то, что у кого то это могут сделать 20 пользователей одновременно

Счета-фактуры не может быть в международном тесте.
Поскольку счет-фактура - российский функционал. Там до инвойса (накладной)

Ничто не мешает проверить. Убери модификации, сделанные внедренцем, свои модификации. Убери российскую функциональность (российская замедляет процентов на 10% http://axapta.mazzy.ru/lib/axapta_benchmark/ ). Отключи индекс хинты. Запусти тесты.

Потом верни все обратно. Запусти тесты.

Найди что тормозит.

[Lazy_Tiger]

Цитата:

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

http://axapta.mazzy.ru/lib/axapta_benchmark_2005/
Пересчет статистики не шаманское действие.
Или я что-то не понимаю.

Угу. Не пересчет, понятно что при апгрейде ее лучше пересчитать, это было сделано. Речь про более сотни дополнительных create statistic трум-пум-пум. То, что реакция на кластерные/некластерные индексы изменилась вплоть до "В РАЗЫ" я вообще молчу.

Кстати. А как расказать аксапте, что не нужно дропать МОИ кластерные индексы при синхронизации?

[mazzy]

Цитата:

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

Речь про более сотни дополнительных create statistic трум-пум-пум.

Насколько я понимаю, такое действие и в 2000 не помешет.

Цитата:

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

Кстати. А как расказать аксапте, что не нужно дропать МОИ кластерные индексы при синхронизации?

Не знаю.

[Lazy_Tiger]

Цитата:

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

Насколько я понимаю, такое действие и в 2000 не помешет.

не помешает, но необходимости в нем не было. производительность более чем устраивала.

ИМХО, как то в сторону Оракла движемся. Как по кол-ву ручечек за которые не просто можно, а НУЖНО дергать, так и по качеству управляющей консоли где теперь сколько нибудь серьезных вещей не сделать, все скриптами

[gl00mie]

Цитата:

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

Кстати. А как расказать аксапте, что не нужно дропать МОИ кластерные индексы при синхронизации?

Не удалять индексы при синхронизации

[Recoilme]

Цитата:

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

А кстати, я НЕ ВЕРЮ что БД была перенесена с SQL2000 на SQL2005 as is. Не верю что не проводилась дополнительная оптимизация. Ибо мой результат на двух проектах - катастрофическое падение производительности. В РАЗЫ. И только после доплнительных шаманских действий по оптимизации индексов, по сбору доп. статистики и т.д. я получил обещанные 25-30% прироста. Так что это лож, п...ж и провокация

А еще я не верю в миф про разноску заказа до счет-фактуры в 5 тыс строк за 5 и даже 10 минут. Тем более не верю в то, что у кого то это могут сделать 20 пользователей одновременно

Выскажу уж и я свое неофициальное мнение))
Основное преимущество SQL server 2005, именно для аксапты, как мне кажется, в том что он умеет есть гораздо бОльшее количество оперативной памяти. Таким образом можно на сервер поставить, например,16 Гиг и, медленно выполняющееся запросы умещаются в кэш, значительно снижается вероятность блокировки. Существенного ускорения 2005 по сравнению с 2000 при отсутствии дедлоков - я не заметил. (делали лог обработки документов). Какие то обработки (большинство) на 2005 начали выполняться незначительно быстрее по сравнению с 2000 (процентов на 10-15, на более мощном железе), какие то наоборот ушли в глубокий даун (на десятки порядков!!!) Лечилось как обычно играми с отключением хинтов и индексами.
Замеры делались на Аксате 3.0, но циферки в версии клиента существенно не влияют.
Таким образом, если нет проблем с мертвыми блокировками, переход на 2005 сервер может не оправдать надежд, но верно и обратное утверждение. Если есть - надо переходить.

Итого: обещанных 30% мы так и не получили. Перешли на гораздо более мощное железо (верхние строчки прайса HP), а выигрыша добились 10-15% .. Но! Зато про дедлоки практически забыли.

[Logger]

Цитата:

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

А кстати, я НЕ ВЕРЮ что БД была перенесена с
А еще я не верю в миф про разноску заказа до счет-фактуры в 5 тыс строк за 5 и даже 10 минут. Тем более не верю в то, что у кого то это могут сделать 20 пользователей одновременно

Скорее всего распараллелили на 50-100 юзеров. Правда тогда число накладных тоже будет 50-100