Проведение по партиям в 1С УПП в традиционном режиме (партионный учет, НЕ РАУЗ) довольно ресурсоемкая операция. В случае если база данных “вашего” предприятия приличных размеров и документов регистрируется очень много это может привести к существенной проблеме. В программном коде УПП есть одно узкое место, которое приводит к существенному увеличению времени выполнения данной операции при повышении объема базы данных.

Информация представленная ниже актуальна для версии УПП 1.3.60.3 и скорее всего для версий более ранних или более поздних, возможно с некоторыми изменениями.

Был произведен замер производительности при котором выявлено, что основной причиной замедления (до 90%) проведения по партиям является “ОбщийМодуль.УправлениеЗапасамиПартионныйУчет”, а именно 3 процедуры из секции “ПОЛУЧЕНИЕ ОСТАТКОВ ИЗ РЕГИСТРОВ ПАРТИЙ”:

В начале этих 3-х процедур имеется текст запроса, которые нам понадобится изменить.

Для анализа возьмём запрос из процедуры “ЗаполнитьЗапросПартийНаСкладахБух()”:

Т.к. данный модуль писали ещё наши дедушки 🙂 имеем следующие проблемы:

Проблема 1:
Сразу бросается в глаза использование вложенных запросов, что не лучшим образом скажется на производительности данных запросов. Пример:

Необходимо перенести код вложенных запросов во временные таблицы.

Проблема 2:
Использование ВНУТРЕННЕГО СОЕДИНЕНИЯ с последующей фильтрацией данных:

Нетрудно представить, что будет со скоростью выполнения данного кода в случае разрастания базы данных.
Требуется внести РегистрСведений.СписанныеТовары во временную таблицу, проиндексировать часть полей и отфильтровать заранее до внутреннего соединения!

Решено изменить код запроса с использованием временных таблиц. Не стану приводить здесь код, добавлю только ссылку на измененные процедуры.

В результате изменения в моем случае прирост скорости проведения по партиям составил, примерно в 5-7 раз.

Пример из жизни выполнения обработки “Проведение по партиям”:

Результаты до изменения кода: за 7 часов работы обработки “проведение по партиям” обрабатывалось 7-8 дней, т.е. около 1 часа на 1 день.

Результаты после изменения кода: за 3.5 часа работы обработки “проведение по партиям” обрабатывалось 26 дней, т.е. около 0.13 часа на 1 день.

Зависимость от размера БД здесь явная. Если ваша база данных ещё не имеет больших размеров, прирост может оказаться не столь внушительным.

Аналогичным образом можно исправить и другие процедуры данного модуля в секции:

такие как:

  • Процедура ЗаполнитьЗапросПартийНаСкладахДляЗакрытияЗаказовПокупателей() (аналогично для БУХ, НАЛ)
  • ЗаполнитьЗапросПартийНаСкладахДляОтложеннойОтгрузкиУпр() (аналогично для БУХ, НАЛ)
  • ЗаполнитьЗапросПартийНаСкладахДляСписанияПоОрдернойСхемеУпр() (аналогично для БУХ, НАЛ)
  • и т.д.

Вконце статьи как и обещал ссылка на текст измененных процедур данной статьи общего модуля “УправлениеЗапасамиПартионныйУчет”:

Общий модуль УправлениеЗапасамиПартионныйУчет_ Модуль

Размещено в , УПП.

Комментарии: 2

  1. посмотрите на infostarte, там намного корректней эти процедуры изменены и универсальнее

    • Спасибо. Я уверен в том, что на infostart реализации более универсальные и правильные, там много интересного и я зарегистрирован там, некоторые свои работы так же выкладываю. Данный пример ускорения был реализован прилично давно без оглядки на какие-то другие ресурсы, т.к. требовалось оперативное вмешательство, т.к. проведение партий перестало укладываться в ночной запуск. Замером производительности в конфигураторе были обнаружены эти недостатки.

Добавить комментарий

Ваш e-mail не будет опубликован.

Яндекс.Метрика