03.03.2016, 09:31 | #1 |
Участник
|
Системы разные нужны, системы разные важны… “Дело было вечером, спорить было не чего.” (с)
…Успешное внедрение Dynamics AX 2012R3 по закупочной логистике все равно вызвало сомнения у руководства компании по продолжению её (DAX) дальнейшего развития и яркое желание использования более популярной в России системы учета (которая не является конкурентом DAX, по словам MS). Были взяты данные по продажам за год на одном из филиалов и загружены в эту популярную систему. Далее была эмулирована работа пользователей по проведению (перепроведению) накладных взятых случайным образом… До 20…25 пользователей система как то дышала, потом не очень… Но речь не о ней, речь об DАХ. Данные результаты интересны лишь потому, что они дали шанс принять ей (DАХ) участие в данном процессе (раньше и не рассматривалось). Итак, начинаем меряться пис…
На основе выгруженных данных необходимо создать заказы на продажу и организовать их резервирование и разноску так, как это бы делали пользователи. Время и трудовые ресурсы ограничены, т.к. требуется продолжать поддерживать работу реальных пользователей. Почти семь миллионов строк (которые хранятся в текстовом файле), из которых должно получиться более 250 000 заказов на продажу. Файл, который открывается то не каждым редактором… :о) Количество строк в некоторых заказах достигает 300-400. По моему опыту, подобная загрузка (с учетом создания клиентов, номенклатур и их количеств на складе) должна выполняться …, т.е. чуть больше, чем было выделено времени на подготовку. Шаг первый, заливаем данные в виде скульной таблицы. Пишем скрипт по формированию из этой таблицы заказов, клиентов, номенклатур с использованием стандартных классов… Получаем совершенно неприемлемый результат… Пробуем распараллелить, загрузка будет выполняется в отдельном потоке, делаем 20 потоков, запускаем с 5 клиентов (итого 100)… Тестовый сервер, на котором так же велись и другие работы, для которых он, в общем-то и был предназначен, получил утилизацию процессоров на 100%. Забавно, но при этом работы можно было проводить, тестирование и разработка не прекращались! Результат - 10 000 заказов за час это уже приемлемо, с этим можно двигаться дальше. Была сделана форма, которая имела ряд настроек: задержка в секундах между операциями и соотношение выполняемых операций резервирования и разноски. Она случайным образом выбирала заказ и выполняла с ним либо резервирование, либо разноску, в зависимости от настроенного соотношения. Количество строк заказа, выполняемая операция и затраченное на нее время логировалось. Планируется открыть N сессий и запустить на них эту форму. Параллельно, несколько человек будут выполнять работы по внесению значений в справочники, ручной разноске и просмотру данных. Необходимо понять, после скольких сессий система станет совсем не комфортна для работы и какое получится среднее время выполнения операций резервирования и разноски на строку? Пробные пуски на тестовом сервере показали, что в среднем резервирование происходит ~90, а разноска ~60 сек. строк в секунду при запуске на 25 сессиях. Если это запустить на рабочем сервере, который в разы производительней мы получим отличные результаты! Стояли, радовались предварительному результату и тут, кто-то, где-то сказал, что более популярная система тратит менее 0,01 сек. на строку при проведении… В это время готовится отдельный виртуальный тестовый сервер на котором будет 3 AOS: чистая система с CU10, система с настройками от виртуальной демомашины с CU9, а также копия нашей рабочей системы очищенная от транзакционных данных с CU7. Конфигурация предоставленного виртуального сервера не порадовала… 8 виртуальных камней, это в 5 раз меньше чем на нашем тестовом рабочем, а 32 ГБ ОЗУ сейчас ставятся на хороший ноутбук… “Может добавим?” - “Нет, для иной популярной программы этого достаточно. Надо поставить вас в одинаковые условия!”. Но после долгих препирательств, все-таки добавили 8 камней. Запустили тесты, конечно, результаты хуже, чем были, но все-таки работать можно… Сначала готовим копию рабочей базы. Перед ее использованием решили ее почистить. SysDataBaseTransDelete сказал, что будет копаться несколько часов. Заменили delete_from на truncate table с учетом deleteActions и быстренько очистили базу. Сделали предварительный тест на малом количестве заказов на всех трех базах, получили следующий результат: Копия нашей рабочей ~45 на резервирование и ~30 строк на разноску в секунду. Чистая база ~124 на резервирование и ~83 на разноску в секунду. База с настройками от демомашины ~36 на резервирование и ~24 на разноску в секунду. Запустили полное создание заказов на всех трех базах, процесс не быстрый, приблизительно на 4 суток. Производительность иной, более популярной программы оценивалась в документах в час, соответственно, пришлось перейти к этому виду оценки. Заказ выбирается по random, после каждой операции резервирование или разноски выполнялся sleep на 10 секунд. При 30 – 40 сессиях процессоры были загружены на 50-60 % результат на всех базах сильно усреднился, стал около ~0.6 документа в секунду для разноски (конечно, возможно, влияние именно выборки заказов). Увеличили загрузку процессоров до 85 - 95%: для копии нашей рабочей при 70 сессиях получили результат 1,54 для резервирования и 1,09 для разноски (33, 22 в строках) для чистой базы 2,2 и 1,5 (48, 33 в строках) для демомашины 2 и 1,4 (44, 28 в строках) документа в секунду. Есть подозрение на влияние установленных обновлений, с последним (CU10) самый лучший результат, с самым ранним (CU7) – худший. |
|
|
За это сообщение автора поблагодарили: Alexius (2), AlGol (2). |
03.03.2016, 09:58 | #2 |
Участник
|
А почему в курилку?
Давайте перенесем в тематический раздел? В администрирование, например. Ну, или в сравнение систем, если вы сранивать с чем-то хотите. оторвать яйца внедренцам. сотни реальных пользователей нормально работают одновременно с автоимпортами и разносками. Цитата:
250тыс - это конечно не у каждого. Но и далеко не единичный случай. Работают же. Пробуем?!!! Так вы тест в одном потоке делали что ли? Му-ха-ха-ха! В общем, дальше я поскипал. Если хотите обсуждать серьезно, то вместо потока мыслей приведите хотя бы число full scan'ов на SQL во время тестирования. Не говоря уж про остальные счетчики. Я так понимаю, что про профилирование и относительное время разноски в модули, в склад и в главную книгу спрашивать бесполезно... ============ Отличный пример... хм... наивного искусства https://yandex.ru/images/search?text...k=1&source=wiz Это не плохо. И имеет право на жизнь. Но имеет свои ограничения )))) DmitryK, если у вас есть веские причины оставлять тему именно в курилке или в каком другом разделе, выскажите их до вечера 03.03.2016, пожалуйста. Если причин не будет, я вечером ветку в администрирование перенесу. Последний раз редактировалось mazzy; 03.03.2016 в 10:01. |
|
03.03.2016, 10:10 | #3 |
Участник
|
Цитата:
Не надо. Здесь достаточно квалифицированные люди, которые в курсе и которые работают в штатном режиме в гораздо более жестких условиях. Поэтому, если хотите услышать какой-то совет - сформулируйте вопрос и приведите данные. Поищите на форуме. Или вот пример http://axapta.mazzy.ru/lib/axapta_itanium/ (хотя и очень старый. вдобавок, и он для публикации сильно упрощен и сокращен) Если же хотите посетовать на жизнь, то таки да - наивное искусство очень выразительно. Это хорошая форма чтобы высказаться о несовершенстве мира ))))) |
|
03.03.2016, 10:17 | #4 |
Участник
|
1С что ли?
Да вы не стесняйтесь. Здесь люди и ее знают. Меня настораживает, что вы сказали "программа", а не "конфигурация". У 1С нет программы. У 1С нет функционала. У 1С работают разные конфигурации на разных платформах. Возможности функционала Dynamics AX и 1С УПП В общем, сформулируйте по-человечески. А то останетесь в истории как очередные сравниватели, которые сначала тестируют, а потом пробуют распараллелить. Последний раз редактировалось mazzy; 03.03.2016 в 10:20. |
|
03.03.2016, 10:26 | #5 |
Участник
|
А вывод то какой ?
Что решили в итоге ? |
|
03.03.2016, 10:26 | #6 |
Участник
|
Цитата:
Сообщение от DmitryK
…Успешное внедрение Dynamics AX 2012R3 по закупочной логистике все равно вызвало сомнения у руководства компании. До 20…25 пользователей система как то дышала, потом не очень… Почти семь миллионов строк (которые хранятся в текстовом файле), из которых должно получиться более 250 000 заказов на продажу...
Конфигурация предоставленного виртуального сервера не порадовала… 8 виртуальных камней, это в 5 раз меньше чем на нашем тестовом рабочем, а 32 ГБ ОЗУ сейчас ставятся на хороший ноутбук… “Может добавим?” - “Нет, для иной популярной программы этого достаточно. Надо поставить вас в одинаковые условия!”. Но после долгих препирательств, все-таки добавили 8 камней. Запустили тесты |
|
|
За это сообщение автора поблагодарили: mazzy (2), rumpleteazer (1), raz (2), Ace of Database (3). |
03.03.2016, 10:28 | #7 |
Участник
|
Кстати если будут попадаться документы с большим числом строк (больше 200) то двумя строками кода можно резко улучшить производительность разноски
Оптимизация класса Tax |
|
|
За это сообщение автора поблагодарили: gl00mie (2), DmitryK (1). |
03.03.2016, 10:43 | #8 |
Участник
|
Сергей, большое спасибо за ваше внимание к данному посту. Но я не хотел бы его делать техническим. По-этому, термины должны быть понятны не только IT' шнику, но и простому смертному (например, руководителю высокого ранга, хозяину бизнеса, который, в основном, оперируют понятием учетная программа ;o). Хотелось поговорить о тенденции, тенденции развития DAХ в России, замены ее на 1С (назову конфигурацию УПП8.3 или может ERP2). Есть ли тенденция замены ее на 1С или это единичный случай? Есть ли перспективы развития DAX в России или не очень? Действительно ли 1С не конкурент? Кто в этом виноват конкретный РП, консалтинг, положение в стране или что еще?
C уважением, Дмитрий. |
|
03.03.2016, 10:55 | #9 |
Участник
|
По поводу того, что 1с ест меньше ресурсов - как-то сомнительно.
Всегда считалось что наоборот. Либо они серьезно допилил систему, либо с тестом что-то не то. |
|
03.03.2016, 10:58 | #10 |
Участник
|
а... понятно. дело хозяйское.
Цитата:
а... да, там много сделали для производительности. разработчики сильно заморачивались. Конечно же есть. Есть и обратные замены. В разделе сравнение и другие системы http://axforum.info/forums/forumdisplay.php?f=29 http://axforum.info/forums/forumdisplay.php?f=102 Также посмотрите на участников, которые состоят в группе 1С http://axforum.info/forums/showgroups.php#12 есть люди, пришедшие из 1С в аксапту, есть люди перешедшие из Аксапты в 1С. учтите что далеко не все знают о группах, и далеко не все заморачиваются Вступить в группу вы можете здесь http://axforum.info/forums/profile.p...editusergroups Группа 1С открытая и для вступления не требуется подтверждения. а это лучше в разделах Microsoft, Партнеры, а также сравнение http://axforum.info/forums/forumdisplay.php?f=52 http://axforum.info/forums/forumdisplay.php?f=3 Отличные вопросы. Вы все-таки сначала почитайте. Обсуждалось не раз. Если вкратце, то ответ зависит от того, про кого вы спрашиваете? Считает ли Майкрософт своим конкурентом 1С? Нет. Считает ли 1С своим конкурентом Майкрософт Dynamics? Да. Считают ли потенциальные покупатели их конкурентами? Да. Считают ли уже купившие пользователи их конкурентами? Нет. Цитата:
и если данную тему здесь оставить, то именно на этот вопрос вы и получите длинный флейм )))))) Последний раз редактировалось mazzy; 03.03.2016 в 11:12. |
|
03.03.2016, 11:08 | #11 |
Участник
|
Цитата:
Если речь идет про ERP2, то там действительно серьезно занимались оптимизацией под большие базы. В итоге в поставке идут индексы, заточенные под большие базы, а не под маленькие рабочие группы, как раньше. В Аксапте индексы из коробки как были "примерными", так и остались до 2012. Для больших баз индексы надо тюнить. В Аксапте это такая же обязательная работа, как и настройка прав. угу. и trancate аксапте делали. И вообще.... поэтому и цифр нет, на мой взгляд. Но дело хозяйское. Другое дело, что подобных "сравнений", которые "должны быть понятны не только IT' шнику, но и простому смертному (например, руководителю высокого ранга, хозяину бизнеса...)" (Бггг!!!! какова формулировка для простого смертного, а?!!! )))))) так вот, подобных "сравнений" становится дофига и больше. 1Совцы меняют приемы. Раньше они говорили "можно сделать". Сейчас вот так. |
|
03.03.2016, 11:37 | #12 |
Участник
|
Так же хочу добавить, что результата сравнения еще нет (хотя есть сильное ощущение, что он может ни на что не повлиять...). Ведь во многих случаях решение принимается так "Мы посоветовались и я решил!" ;о)
|
|
03.03.2016, 11:50 | #13 |
Участник
|
|
|
03.03.2016, 12:34 | #14 |
Участник
|
|
|
03.03.2016, 12:40 | #15 |
Участник
|
Цитата:
Были взяты данные по продажам за год на одном из филиалов и загружены в эту популярную систему. Далее была эмулирована работа пользователей по проведению (перепроведению) накладных взятых случайным образом… До 20…25 пользователей система как то дышала, потом не очень…
|
|
03.03.2016, 13:13 | #16 |
Участник
|
Да, на сколько мне известно, на данном сервере, при большом количестве пользователей работа стала невозможной и появились exeptions.
"Но речь не о ней, речь об DАХ. Данные результаты интересны лишь потому, что они дали шанс принять ей (DАХ) участ..." ;о) C уважением, Дмитрий. |
|
03.03.2016, 16:48 | #17 |
Участник
|
Результаты были перепроверены “независимым” экспертом… Резюме - сравнивать нечего, 1С не жила при 20 сессиях, DAX – нормально работает при 50. Посмотрим, повлияет ли этот результат на дальнейшее развитие проекта DAX?
Последний раз редактировалось DmitryK; 03.03.2016 в 16:58. |
|
03.03.2016, 16:58 | #18 |
Участник
|
Если вы на тесте использовали "чистый" функционал АХ, без докручивания индексов, то у АХ есть потенциал для ускорения, в 1С с ними более грустно - нужно ваять в сторонке
|
|
03.03.2016, 17:12 | #19 |
Участник
|
Нормально установленная и настроенная ERP 2.0 спокойно тянет 100-200 пользователей. Железо при этом примерно сопоставимо с железом для Акс на такое же количество пользователей. Если ставить совсем дохлое железо, что Акс работает на 50 пользователей "впритык", 1С может себя показывать хуже, но не намного.
__________________
Ivanhoe as is.. |
|
03.03.2016, 17:29 | #20 |
Участник
|
Я так понимаю что цель как раз и заключалась в том чтобы подобрать такую нагрузку / железо, чтобы было видно какая из систем лучше использует мощности.
Иначе какой смысл проводить тест, при котором получится что обе системы функционируют нормально в поставленных условиях. Это неинформативно для целей выбора. Вообще конечно интересно посмотреть подробнее на конфигурацию оборудования и нагрузку. |
|