Системы разные нужны, системы разные важны… “Дело было вечером, спорить было не чего.” (с)

[DmitryK]

…Успешное внедрение 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) – худший.