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

[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).