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

[mazzy]

Microsoft Dynamics AX 4.0 white paper: Benchmarking on Hewlett-Packard Proliant Servers

[komar]

Начинается..... вот так же и с версией 2.5 было....
Предлагаю для лучшей репрезентативности тестов установить на сервера локализованную версию...."the schetfactura" показатели подправит

[mazzy]

Обсуждение виртуальной памяти выделено в отдельную ветку А построение перекрестных ссылок опять сожрет всю память и завесит систему нафих

[komar]

Так я как раз про то - в международной версии нет наших фактур, наворотов на сопоставлении с курсовыми разницами, основных средств. Поэтому работаю с 1000 пользователей на российской версии клиент рискует получить скорость, весьма далекую от бенчмарка (можно, конечно, предложить ему тоже работать без фактур и суммовых, равно как и не пользоваться функционалом, не вошедшим в тестовый пример по бухучету, ибо нефиг).
Тестирование на примере без фактур и прочих радостей представляет собой "сферическую лошадь в вакууме", с тем же успехом можно було просто нагенерить 10000 проводок по ГК, и установить, что система умеет быстро записывать в журнал проводки (а потом их разнести, одним журналом желательно - так хотя бы будет наглядно видно, что решены все проблемы с памятью)

[mazzy]

Цитата:

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

Так я как раз про то - в международной версии нет наших фактур, наворотов на сопоставлении с курсовыми разницами, основных средств. Поэтому работаю с 1000 пользователей на российской версии клиент рискует получить скорость, весьма далекую от бенчмарка (можно, конечно, предложить ему тоже работать без фактур и суммовых, равно как и не пользоваться функционалом, не вошедшим в тестовый пример по бухучету, ибо нефиг).
Тестирование на примере без фактур и прочих радостей представляет собой "сферическую лошадь в вакууме", с тем же успехом можно було просто нагенерить 10000 проводок по ГК, и установить, что система умеет быстро записывать в журнал проводки (а потом их разнести, одним журналом желательно - так хотя бы будет наглядно видно, что решены все проблемы с памятью)

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

Для начала:
= в международной версии есть ОС
= в международной версии есть функционал, который не используется в России (и это не самый легкий функционал)

Во-вторых:
"генерация 10000 проводок по ГК" будет выполнена медленнее, чем выполнение скриптов. Подумай почему... Даю маячок - в прес-релизе задействованы разные таблицы.

Далее по самой методике тестирования производительности:
Обрати внимание на детализацию сценариев.
Обрати внимание, что расписано что каждый пользователь делает.
Обрати внимание, что эти сценарии являются стандартными и содержатся в стандартной Аксапте.
Обрати внимание, что эти сценарии каждый может повторить в своих условиях
И каждый может проверить насколько цифры в пресс-релизе отличаются от полученных в собственных условиях.

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

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

Почему только "фактуры" должны быть включены в тест?
Почему не весь имеющийся в Аксапте функционал?
Достаточно ли для целей тестирования задействовать самый общие и самые востребованные на рынке функции?

Какая методика должна быть в тесте на твой взгляд?

[komar]

Думаю, ты отлично понимаешь, о чем я говорю. А говорю я о том, что посадив реальных пользователей выполнять реальные операции, мы не получим заявленных результатов. Не думаю, что это является для кого-либо новостью.

[Serge Kotov]

Цитата:

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

... А говорю я о том, что посадив реальных пользователей выполнять реальные операции, мы не получим заявленных результатов. Не думаю, что это является для кого-либо новостью.

Ранее я сравнивал результаты теста http://axapta.mazzy.ru/lib/axapta_benchmark/ с результатами действующей системы в промышленной эксплуатации и с учетом коррекции в отличии в архитектуре тестовой и действующей системы убедился в точности результатов теста. Им можно доверять .

Это совместно с другими факторами позволило в дальнейшем с точностью до + - 30 % планировать результаты по производительности при реализации аппаратной архитектуры систем, даже отличающихся по характеристикам.

Просто надо уметь пользоваться результатами, тем более если они были представлены в такой подробной форме...

[komar]

Цитата:

Сообщение от Serge Kotov

Просто надо уметь пользоваться результатами, ...

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

[Serge Kotov]

Цитата:

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

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

ОК Как говорится, каждый пользуется в меру своей испорченности

[komar]

Не сказал бы, чтобы форма была очень подробной...я так и не просек, фактура там была или нет? И если возможно сравнивать с учетом отличий, то каков поправочный коэфициент на фактуру?
И неужели в промышленной было ровно столько (более 1000) юзеров? И все "стандартные", или все-таки реальные грузят систему больше?
И разве 30% - это достаточная точность?

[Serge Kotov]

Цитата:

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

Не сказал бы, чтобы форма была очень подробной...я так и не просек, фактура там была или нет? И если возможно сравнивать с учетом отличий, то каков поправочный коэфициент на фактуру?
И неужели в промышленной было ровно столько (более 1000) юзеров? И все "стандартные", или все-таки реальные грузят систему больше?
И разве 30% - это достаточная точность?

Не зря придумали понятие стандартный пользователь - ASU и даже где-то я видел таблицу приведения стандартных к реальным с коэффициентами 0.5, 3 и т.д.

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

Точность 30% на самом деле вполне достаточна для планирования при сложных многофакторных изменениях. Вот, например, совсем недавно мы перевели одну из наших систем с 2000-го на SQL 2005 со сменой сервера БД (с 6 процессорного на 2-х процессорный). Ожидалось, что контрольные операции будут выполняться вдвое быстрее. По факту оказался рост ~150%. Разумеется пользователи были не против. Если бы производительность возросла только на 70%, это также был бы вполне приемлемый результат, оправдывающий затраты на переход. При планировании в данном случае кстати лучше несколько занижать ожидания у заказчика.

[komar]

Коэффициент, как выяснилось, около 3 - Тест Columbus IT/Microsoft: решение "Юнимилк" способно обслуживать 1300 пользователей
Но разве можно утверждать, что зависимость исключительно линейная? То есть до какого-то момента, наверное, можно. Но не факт, что если 300 пользователей буду работать с заданной скоростью на 2 АОСах, то 30000 будут работать с той же скоростью на 100. То есть мне кажется некорректным подтверждать реальной инсталляцией, скажем на 300 пользователей корректность тестов на 1000 и более абстрактных виртуальных юзеров. Посему наиболее убедительно выглядела бы ссылка на конфигурации оборудования компаний, у которых эта тысяча есть (по слухам, где-то есть такая инсталляция - вот ее бы и обсуждать!). С реальными данными спорить трудно...может, кто поделится?

[komar]

Другими словами - предположим, что реальными инсталляциями подтверждаются результаты тестирования до N пользователей (видимо, 300-500 человек), то есть реально создать такой тестовый сценарий, который бы с пристойной точностью показывал бы, какую нагрузку и какое быстродействие мы будем иметь, посадив за систему, скажем 300 операторов. Далее, как в тесте, на который я ссылался в предыдущем посте, загрузка одного виртуального юзера признается эталонной, генерится 1000 таких "роботов", и получаются результаты, с некоторой натяжкой дающие представление о загрузке системы реальными людьми (подход имеет свои ограничения, так как при этом никто не следил за качеством вычислений системы, и тестировались не все возможные операции, ..... - но тест есть тест, это хоть что-то).
Но вот дальше происходит нечто необъяснимое - из этого делается вывод, что и тесты на большее количество человек (при этом сделанные, возможно, с использованием другого тестового сценария) - также имеют ту же степень точности, то есть фактически безграничная масштабируемость системы принимается за аксиому.

[mazzy]

Цитата:

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

предположим, что...

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

Цитата:

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

Но вот дальше происходит нечто необъяснимое - из этого делается вывод, что и тесты на большее количество человек (при этом сделанные, возможно, с использованием другого тестового сценария) - также имеют ту же степень точности, то есть фактически безграничная масштабируемость системы принимается за аксиому.

Твое утверждение ложно.
Стоит подумать еще раз.

[komar]

Доку не хочу. Хочу живую инсталляцию.

[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 не помешет.

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

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