Долго проверяются марки ЧЗ в Рознице
Клиент обратился с проблемой, что у него долго проверяются и никак не заканчивается проверка марок ЧЗ.
Накладная на сигареты, там 89.000 пачек, сгруппированных в блоки и ящики.
Во-первых я включил режим отладки, чтобы быть уверенным, что не отвалится фоновое задание.
В процедуре ИнтерфейсМОТП.ДеревоУпаковок 178 пакетов по 500 элементов. это 89000 кодов, в одном пакете запроса в ЧЗ 500 марок:
Конечно, 1С не позаботилось о пользователях и индикатор прогресса не сделало.
Видимо, тестировало на небольших объемах.
Но когда казалось, что самое страшное (запросы к ЧЗ) уже позади, 1С начала мучительно и долго обрабатывать дерево упаковок:
Чтобы вы понимали скорость, на эти 85.000 упаковок сотни миллионов вызовов в процедурах заполнения массивов:
Где ты питон или ассемблер, когда вы так нужны?
Почему же 1С не использовала запросы, почему 89.000 позиций вылились в сотни миллионов строк? Нет ответа. Не умеют 1С работать с Big Data, да что там, даже 100 тысяч марок не в силах одолеть в разумные сроки.
Среда: Розница 3.0.13.260
А на чëм конкретно тормозит, это запрос к БД, внешнему сервису, или какая-то трансформация данных внутри 1С? 100к это далеко-далеко не биг дата.
Не спец по 1с, но похоже у них там где-то просто набор вложенных циклов. в итоге на небольшом числе элементов у нас вылетает n ^ 3 если не больше, вот всё и тормозит. В данном случае Сергей прав — кривые программисты.
думаю, там не просто «тормозит», а «никогда не завершится за разумное время».
1с-ники потестировали на 1000 марок и подумали, что на 80.000 будет работать аналогично.
Ан нет.
там на 80 тысячах марок идут какие-то дикие рекурсии и постоянный вызов добавления элементов не уникально в массивы по строкам деревьев.
Какой-то сон разума.
на замерах видны сотни миллионов проходов заполнения соответствия уникальных значений…
конца пользователь так и не дождался.
будет обращаться в поддержку, благо он на ИТС со своим «фу-фу-фу».
Проблема не в запросах в ЧЗ, а уже в последующем отражении в дереве упаковок.