Каталог решений - Ускорение расчета себестоимости УПП 1.3 в несколько раз

Всем доброго времени суток! 

На днях столкнулся с задачей: долго рассчитывается себестоимость по организации за декабрь 2020 года (~40 минут), при этом в ноябре и всех прошлых месяцах она рассчитывалась ~10 минут.

Что имеем: платформа 8.3.16.1359, УПП 1.3 (1.3.152.3), PostgreSQL (тестировалось и на MS SQL), производственная организация, партионный учет, многопередельное производство. 

Если вы столкнулись с такой же или похожей проблемой, то эта статья может натолкнуть на решение и сэкономить вам время.

Первым делом, следует выполнить пересчет итогов регистров — правда в контексте этой задачи, у меня ничего не изменилось.

Далее заходим в конфигуратор, запускаем режим отладки (F5) — запускается режим предприятия — находим нужный документ расчета себестоимости — возвращаемся в конфигуратор — активируем режим замера производительности:

возвращаемся в предприятие — запускаем проведение расчета себестоимости — ждем окончания.

После того, как расчет себестоимости завершен, возвращаемся в конфигуратор и останавливаем замер производительности:

на экране появится результат замера, подробно расшифровывать не будем, кому интересно можно почитать подробнее об этом инструменте https://its.1c.ru/db/metod8dev/content/1553/hdoc .

Итак, мой результат:

В глаза сразу бросается первая строка, мы видим, что данная строка кода выполняется 32 раза, 2 268,979787 секунд (~38 минут) и занимает 85,61% всего времени выполнения проведения расчета себестоимости.

Познакомимся ближе с этой строкой, дважды щелкаем на строку в замере производительности, попадем в модуль — в место выполнения этого кода, эта строка находится в общем модуле ПроцедурыРасчетаСебестоимостиВыпуска.

Ставим точку останова на данной строке кода:

Снова возвращаемся в предприятие и еще раз проводим расчет себестоимости, пока выполнение кода не остановится на нашей точке:

Выделяем ЗапросПоЗатратамНаВыпуск нажимаем Shift + F9:

теперь, у нас есть текст выполняемого запроса и его параметры, чтобы было удобно работать с этим запросом, нам необходимо, вернуться в пользовательский режим, запустить любую консоль запросов, скопировать туда текст запроса и заполнить параметры.

Кстати параметров очень много, да еще и массивы, очень удобно использовать подсистему инструменты разработчика, чем я и воспользуюсь, подробнее здесь //sale.itcity.ru/public/15126/ .

У меня уже встроена эта подсистема и чтобы получить запрос из отладки со всеми параметрами в пользовательском режиме, мне достаточно нажать SHIFT + F9 и написать Отладить() , указав в качестве параметра свой запрос, далее нажать вычислить:

В режиме предприятия открывается консоль запросов, уже с заполненным текстом и параметрами, остается только выполнить:

Запрос возвращает 285 строк, за 195 секунд. Я решил проанализировать прошлые месяцы, меняя параметры периода в запросе и увидел, что действительно в прошлых месяцах количество строк было примерно в 3.5 раза меньше, (вспоминаем постановку задачи, выполнялось за 10 минут, стало за 40) действительно, пропорционально увеличению записей в регистре, увеличилось и время расчета себестоимости, к слову, записи увеличились обоснованно, из-за включения серий. 

Собственно, с причиной разобрались, но неужели так и придется жить, ведь сейчас на предприятии даже не сезон, дальше будет еще дольше выполняться расчет, а один раз себестоимость редко проводится, далеко не всегда всё закрывается идеально с первого раза, сколько времени придется убить на закрытие месяца.

Это не устраивает. 

Возвращаемся к нашему запросу и анализируем его:

в качестве основной используется таблица регистра накопления, к ней соединяются 4 вложенных запроса.

Вспоминаем методику:

Фирма 1С не рекомендует использовать вложенные запросы без особой потребности и предлагает заменять их временными таблицами или соединениями таблиц, замечая при этом, что результат такого изменения может быть другим. Такая рекомендация объясняется тем, что при использовании вложенных запросов оптимизатор СУБД не всегда может правильно определить размер выборки вложенного запроса и построить оптимальный план обращений к физическим таблицам базы данных, что сильно (иногда в десятки раз) может замедлить выполнение запроса.

А здесь, еще подробнее https://its.1c.ru/db/v8std/content/655/hdoc@51ff9ba0 .

Прислушаемся к совету, модернизируем запрос, заменив все вложенные запросы на временные таблицы, проиндексировав их по полях соединений(ниже будет итоговый текст запроса):

выполняем запрос в консоли:

видим, что скорость выполнения увеличилась со 195 секунд до 0.5 секунд!!! то, что надо, теперь внедрим его в конфигурацию и попробуем выполнить расчет себестоимости с замером производительности, для этого в общем модуле ПроцедурыРасчетаСебестоимостиВыпуска, находим функцию СформироватьТекстЗапросаПоЗатратамНаВыпуск(), и заменяем ее, на наш запрос с временными индексированными таблицами, типовой запрос опциональный — с использованием в тексте комментариев, которые потом в зависимости от параметров учета, заменяются на строки кода, наш запрос ничем не хуже и также будет опционален.