Решение проблемы медленной загрузки документов в модуле Диадок на примере УТ 10.3
Частный случай повышения производительности работы модуля Диадок на конфигурации УТ 10.3. Испробованы способы типовой оптимизации от 1С путем добавления ресурса в индексированные поля. Но результат дал только способ с нарушением рекомендаций 1С.
Добрый день коллеги.
Обычно я не пишу статей, но решился на этот опус из соображений массовости использования решения Контура модуль Диадок для 1С. Также понимаю, что многие еще используют УТ 10.3 или УПП и могут сталкиваться с похожей деградацией.
Постараюсь описать решение достаточно подробно, но применять его БЕЗ ПОНИМАНИЯ механизма работы SQL крайне не рекомендую. Решение будет предложено для связки 1С + MS SQL.
Суть проблемы. У нас достаточно большая база (конечно для каждого это свои показатели), с большим количеством объектов и свойств для них. Модуль Дидока в моей связке (УТ 10.3 + Диадок) хранит свои стыковки контрагентов также в регистре сведений ЗначенияСвойствОбъектов. И при загрузке списка документов он в цикле, по каждому документу из списка получает сопоставление с объектом из базы данных (в данном случае Контрагентом) выполняя такой запрос:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
ЗначенияСвойствОбъектов.Объект КАК Ссылка
ИЗ
РегистрСведений.ЗначенияСвойствОбъектов КАК ЗначенияСвойствОбъектов
ГДЕ
ЗначенияСвойствОбъектов.Значение = &Значение
И ЗначенияСвойствОбъектов.Свойство = &Свойство
УПОРЯДОЧИТЬ ПО
Ссылка
АВТОУПОРЯДОЧИВАНИЕЕсли же посмотреть структуру самого регистра, то видно что он индексируется по двум измерениям. То есть создаются 2 индекса Объект, Свойство и Свойство, Объект.
Естественно, при поиске по запросу приведенному выше оба эти индекса не будут использоваться. Подтверждать это предоставлением плана исполнения запроса не хочу. (Прошу прощения.) Опираюсь лишь на свой опыт.
Первоначально возникает идея попытаться использовать возможности платформы и сделать единственный ресурс Индексированным.
Теперь немного примеров. Получение документов за квартал на одной базе без прочей нагрузки, срез до изменений. (Статистика свежая, индексы перестроены.)
Теперь посмотрим, что произойдет после индексации ресурса. (Статистика также свежая, индексы перестроены.)
Как видим ничего не изменилось. Небольшое изменение времени исполнения (в процентном выражении) я отношу к тому, что эксперименты я делаю на продуктивном сервере. Хоть база и вынесена на отдельный диск, но прочая нагрузка на сервер остается.
Почему не помогает в данном случае индексация поля. Смотрим структуру БД средствами 1С.
Значение ушло в начало индекса, а делее мы получаем порядок измерений, в том виде в котором они идут в конфигураторе.
Нам же требуется, чтобы Объект был последним, то есть Значение, Свойство, Объект. Почему Объект лучше оставить. Так как он выводится в результате запроса, да и этим достигается большая точность (ИМХО как и всё прочее).
Ну раз типовыми средствами не получилось добиться результата, идем дальше. (Конечно, если я не смог добиться лишь потому, что ограничен в познаниях, буду рад если сообщество подскажет более корректное решение данной задачи.)
Запускаем Management studio, находим наш созданный индекс и в контекстном меню Создать скрипт — Используя CREATE. Выводим куда вам удобнее, в новое окно и тп.
Далее меняем порядок, Свойство поднимаем перед Объектом.
Выполняем скрипт в своей базе. В результате получаем даже без обновления статистики следующий результат.
Как видно увеличение производительности произошло более чем в 10 раз. Проблема деградации производительности решена.
Естественно, на продуктивной базе я не буду создавать промежуточный индекс, который не принес результатов. Создам только нужный.
Еще раз повторю, статья создана лишь для описания своей частной точки зрения на оптимизацию работы 1С. Использовать его или нет, каждый программист 1С должен решать сам.
Спасибо за внимание, и я буду рад, если кому-то это поможет в его работе.
