Тест Columbus IT/Microsoft: решение "Юнимилк" способно обслуживать 1300 пользователей

[itfs]

Похоже на бред, особенно 1300 одновр. пользователей. Какая версия AX? Eсли 3.0, больше 900 - не верю, не может этого быть, в принципе, ни на какой платформе, ни на каком оборудовании. (ИХМО, конечно).

С уважением, itfs.

[Yoil]

Цитата:

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

Похоже на бред, особенно 1300 одновр. пользователей. Какая версия AX? Eсли 3.0, больше 900 - не верю, не может этого быть, в принципе, ни на какой платформе, ни на каком оборудовании. (ИХМО, конечно).

С уважением, itfs.

itfs, а почему именно 900, а не 814 и не 987?

[Morpheus]

Цитата:

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

Eсли 3.0, больше 900 - не верю, не может этого быть, в принципе, ни на какой платформе, ни на каком оборудовании.

Интересуют аргументы?

[itfs]

Цитата:

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

Интересуют аргументы?

Спасибо, что не факты . Итак, агрументы:
Утв1. На одном AOS одновременное могут работать максимум 150 одновр. пользователей, это связано с ограничением в 2Гб на размер виртуальной памяти, с которым AOS работает корректно.
Утв2. В конфигурацию вставка более чем 6-го AOS-а никак не сказывается на масштабируемости системы вцелом, т.е. 7-й AOS подцепить можно, улучшить этим производительность системы нельзя.

Лемму я сформулироват в предыдущем посте. Доказательство предоставляется в качестве упражнения всем желающим.

С уважением, itfs.

[Kamill_A]

Коллеги!

1. Всем спасибо за комментарии.

2. Отчет о тестировании:

На этом сайте в архиве RAR (извините за качество графики, но сами знаете, какие здесь ограничения): 1300user.rar

Полный вариант отчета (и официальный пресс-релиз)

3. Хотелось бы надеяться, что, как таковая, новость о возможностях масштабирования Microsoft Dynamics AX будет воспринята пользователями данного форума позитивно.

[mazzy]

Спасибо

[komar]

Цитата:

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

Спасибо, что не факты . Итак, агрументы:
Утв1. На одном AOS одновременное могут работать максимум 150 одновр. пользователей, это связано с ограничением в 2Гб на размер виртуальной памяти, с которым AOS работает корректно.
Утв2. В конфигурацию вставка более чем 6-го AOS-а никак не сказывается на масштабируемости системы вцелом, т.е. 7-й AOS подцепить можно, улучшить этим производительность системы нельзя.

Лемму я сформулироват в предыдущем посте. Доказательство предоставляется в качестве упражнения всем желающим.

С уважением, itfs.

А почему 7 АОС не сказывается? Вот написано, аж 20 штук подцепили...и терминал еще...неслабая батарея...правда, в предыдущих тестах на много народу вроде использовали меньше железа - вот здесь http://www.russianenterprisesolution...s/01/1010.html написано, что такой батареи АОСов, да без всяких терминалов хватает аж на 3600 пользователей...или это и есть "понижающий коэфициент", так сказать, поправка на русскую версию - то есть работает она примерно в 3 раза медленнее? Просто никак не догоню, какой иначе был смысл рапортовать о 1300 пользователей, когда можно сгенерить в 3 раза больше?

[itfs]

Цитата:

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

А почему 7 АОС не сказывается? Вот написано, аж 20 штук подцепили...и терминал еще...неслабая батарея...правда, в предыдущих тестах на много народу вроде использовали меньше железа - вот здесь http://www.russianenterprisesolution...s/01/1010.html написано, что такой батареи АОСов, да без всяких терминалов хватает аж на 3600 пользователей...или это и есть "понижающий коэфициент", так сказать, поправка на русскую версию - то есть работает она примерно в 3 раза медленнее? Просто никак не догоню, какой иначе был смысл рапортовать о 1300 пользователей, когда можно сгенерить в 3 раза больше?

Ну вы своим вопросом вобщем-то и ответили, как думаете, сколько времени займет синхронизация этих 20-ти aos-ов?
Да, дело-то вобщем не в подборе аргументов. Какая разница кто из нас сейчас в ударе и в состоянии что-то эдакое резюмировать? Вообще, я предлагаю смотреть на проблему более со стороны. Любая архитектура имеет свои ограничения. Это не стыдно, это ХОРОШО! Это не плюс и не минус, это свойство. Давайте воспринимать его отстраненно. Все что нам нужно, это разумно этим пользоваться. Мы ведь профессионалы, и не в области маркетинга, слава богу. Считайте, что я медитировал над архитектурой и пришел к таким выводам. Ну не может эта система масштабироваться до бесконечности. Для маркетологов это не повод отступать, когда надо показать товар лицом. Молодцы! Уважаю!
А что касается самого пресс-релиза он составлен по другим законам. Клиент хотел получить "подтверждение", он его получил. Для кого-то гадание на кофейной гуще является подтверждением не менее серьзным. Я, и мое мнение, тут совсем ни при чем.

С уважением, itfs.

[AERM]

Цитата:

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

А почему 7 АОС не сказывается? Вот написано, аж 20 штук подцепили...и терминал еще...неслабая батарея...правда, в предыдущих тестах на много народу вроде использовали меньше железа - вот здесь http://www.russianenterprisesolution...s/01/1010.html написано, что такой батареи АОСов, да без всяких терминалов хватает аж на 3600 пользователей...или это и есть "понижающий коэфициент", так сказать, поправка на русскую версию - то есть работает она примерно в 3 раза медленнее? Просто никак не догоню, какой иначе был смысл рапортовать о 1300 пользователей, когда можно сгенерить в 3 раза больше?

Уважаемый komar, читайте, пожалуйста, отчеты внимательнее. Слышали про стандартного пользователя ASU? 1 ASU = 50 обработанных строк заказов в час. Так вот, в приведенной вами выше ссылке на тестирование, речь идет как раз о 3600 ASU, причем в режиме клиента как нити AOS и с использованием стандартного сценария BM (SO-BS), на сгенерированных этим же BM данных с определенным коэффициентом множественности. Именно так и проводятся все стандартные тесты, именно поэтому их и можно сравнивать между собой.

В обсуждаемом же здесь пресс-релизе речь идет о тестировании РЕАЛЬНОГО приложения компании Юнимилк, на РЕАЛЬНЫХ данных (заметьте, размером более 360 Гб) и РЕАЛЬНЫХ операциях. Мы потратили достаточно сил, для того, чтобы создать сценарии, которые с минимальной погрешностью повторяют поведение пользователей рабочей системы. Именно для этого был создан и проверен эталонный тест на 300 пользователей, который, кроме всего прочего, был проверен на рабочем оборудовании Юнимилка во время технологического останова (окна). Мы повторили реальную рабочую нагрузку, а затем плавно масштабировали систему, добавляя оборудование. В нашем тесте 300, 600, 900, 1300 пользователей работало полностью в интерфейсном режиме, выполняя реальные операции и создавая нагрузку, т.е. именно так, как работают реальные пользователи, запуская ax32.exe.

Очевидно, что проводя такое масштабное тестирование (нам пришлось ехать в Германию, т.к. подходящего оборудования в России мы, к сожалению, не нашли), мы не упустили возможности провести еще несколько интересных тестов: только вышедшей тогда AX4.0 (build 1633.10)!!!, а также сравнительный тест 3.0 и 4.0 на одинаковом оборудовании, данных и сценариях. Вот в данном случае, мы использовали как раз стандартный сценарий SO-BS и результаты, которые мы получили, можно легко сравнивать с теми скромными 3600 ASU . К концу октября выйдет пресс-релиз и детальные отчеты, посвященные данному событию.

Суважением,
Anatoly Ermakov | Director, Solution Development Office
Columbus IT | Kozhevnichesky pr. 4-8 | 115114 Moscow | Russia

[ziva]

Цитата:

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

В обсуждаемом же здесь пресс-релизе речь идет о тестировании РЕАЛЬНОГО приложения компании Юнимилк, на РЕАЛЬНЫХ данных (заметьте, размером более 360 Гб) и РЕАЛЬНЫХ операциях. Мы потратили достаточно сил, для того, чтобы создать сценарии, которые с минимальной погрешностью повторяют поведение пользователей рабочей системы. Именно для этого был создан и проверен эталонный тест на 300 пользователей, который, кроме всего прочего, был проверен на рабочем оборудовании Юнимилка во время технологического останова (окна). Мы повторили реальную рабочую нагрузку, а затем плавно масштабировали систему, добавляя оборудование. В нашем тесте 300, 600, 900, 1300 пользователей работало полностью в интерфейсном режиме, выполняя реальные операции и создавая нагрузку, т.е. именно так, как работают реальные пользователи, запуская ax32.exe.

Цитата:

Из отчета:
Проведенное тестирование показало высокую масштабируемость клиентской версии Microsoft Dynamics AX 3.0 компании «Юнимилк». Была достигнута основная цель тестирования: работоспособность системы при 1300 одновременных пользователях и сохранение временных параметров выполнения операций.

Насколько я понял, в рамках тестирования не рассматривались регламентные операции, своевременное выполнение которых может стать очень критичным фактором.
Используется ли клиентом (компанией "Юнимилк") операция закрытия склада? Если да, то можете ли привести показатели производительности данной операции?
Например, у нас 1 млн. складских проводок закрывается за 45 минут.

Стоит ли нам ожидать появления еще одного пресс-релиза от Columbus IT на эту тему?

[AERM]

Цитата:

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

Насколько я понял, в рамках тестирования не рассматривались регламентные операции, своевременное выполнение которых может стать очень критичным фактором.
Используется ли клиентом (компанией "Юнимилк") операция закрытия склада? Если да, то можете ли привести показатели производительности данной операции?
Например, у нас 1 млн. складских проводок закрывается за 45 минут.

Стоит ли нам ожидать появления еще одного пресс-релиза от Columbus IT на эту тему?

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

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

Я уже писал на этом форуме, что до конца октября появится наш совместный с Microsoft пресс-релиз по сравненительному тестированию 3.0 и 4.0 и тестированию 4.0 на максимум ASU (все версии стандартные международные). Основной сценарий тестирования - создание и разноска заказов (SO-BS).