1c-crm-red
От экспертов «1С-Рарус»: Неожиданная причина долгого открытия формы в «1С»
16.06.2020

От экспертов «1С-Рарус»: Неожиданная причина долгого открытия формы в «1С»

Первое открытие «Интереса» после запуска УТиВСК 3 занимает больше 15 секунд

К нам обратился клиент с жалобой на слишком долгое открытие формы документа «Интерес» в решении «1С:Управление торговлей и взаимоотношениями с клиентами, ред. 3» (УТиВСК 3). Причем наблюдалось это только при включенных ограничениях доступа на уровне записей и только в первый раз после запуска программы. Все последующие открытия этой же формы происходили быстро. Выглядело это так (рис. 1).

Рис. 1 Долгое первое открытие формы

Рис. 1 Долгое первое открытие формы

Ограничения доступа на уровне записей (RLS) являются неотъемлемой частью решений на платформе 1С:Предприятие для среднего и крупного бизнеса. Они позволяют разграничить доступ к данным на основе значений этих данных. Например, можно дать менеджерам по продажам возможность видеть только своих клиентов. Давно известно, что включение RLS серьезно замедляет многие операции, и поэтому общепринятая рекомендация — включать только те RLS, без которых обойтись нельзя.

В программе УТиВСК 3 документ «Интерес» аккумулирует в себе всю информацию по ведению сделок с клиентами, и время открытия этого документа критически важно для качества программного продукта.

Исходная ситуация

Окружение

  • Решение: УтиВСК 3.
  • Платформа 1С: 8.3.13 и выше.
  • ОС: Windows 7 и выше, Windows Server 2008 и выше.
  • СУБД MS SQL 2014 и выше.

Описание проблемы

  • В базе включены RLS (вариант работы «Стандартный»).
  • На форме документа «Интерес» есть несколько «тяжелых» динамических списков.
  • Под пользователем с полными правами первое после запуска программы открытие формы занимает 3,5 сек, последующие — 2 сек.
  • Под пользователем с ограниченными правами (менеджер по продажам) первое открытие формы занимает 15 сек и более, последующие — 2 сек.

Проверяем RLS и SQL-запросы

Предположения и сбор материалов

Известно, что включение RLS замедляет операции из-за добавления к запросам дополнительных условий. Однако, в нашем случае операция выполняется долго не всегда, а только в первый раз. Предположительно, это могло объясняться тем, что при инициализации формы вызываются общие модули с повторным использованием значений.

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

Исходя из этого, было принято решение искать долгие запросы с RLS, выполняющиеся в модулях с повторным использованием. Для этого был собран технологический журнал с событиями CALL и DBMSSQL (рис. 2).

Рис. 2 Настройка сбора событий технологического журнала и собранные данные

Рис. 2 Настройка сбора событий технологического журнала и собранные данные

Анализ

Собранные данные были обработаны скриптами на основе регулярных выражений для получения топа вызовов по длительности событий. В топе серверных вызовов виден явный лидер. Это вызов получения формы длительностью 14,3 сек. Приходим к выводу, что практически все время исследуемой операции — это время одного серверного вызова (рис. 3).

Рис.3 Топ серверных вызовов по длительности и скрипт, которым он был получен

Рис.3 Топ серверных вызовов по длительности и скрипт, которым он был получен

В топе запросов также есть лидер, его длительность 1,3 сек. Это явно неоптимальный запрос, но он не оказывает решающего вклада в длительность вызова (рис. 4).

Рис. 4 Топ SQL-запросов по длительности и скрипт, которым он был получен

Рис. 4 Топ SQL-запросов по длительности и скрипт, которым он был получен

Также, все прочие запросы имеют длительность менее 0,05 сек каждый (рис. 5).

Рис. 5 Топ SQL-запросов по длительности (продолжение)

Рис. 5 Топ SQL-запросов по длительности (продолжение)

Из этого следует, что долгое первое открытие формы не объясняется долгим выполнением запросов. Необходимо выдвигать другие гипотезы.

Больше внимания RLS

Предположения и сбор материалов — вторая итерация

При анализе собранного технологического журнала замечено, что тексты запросов, выполняющихся во время вызовов, очень объемные и сложные. Но при этом запросы быстро выполняются. Например, исполняемый СУБД текст самого длительного запроса содержит более 3300 строк, размер — 266 КБ (рис. 6).

Рис. 6 Количество строк и размер текста самого длительного SQL-запроса

Рис. 6 Количество строк и размер текста самого длительного SQL-запроса

В связи с этим можно предположить, что основные затраты времени приходятся на формирование текстов запросов с RLS. Было решено снова собрать технологический журнал, но на этот раз включить в него событие SDBL (рис. 7).

Рис. 7 Настройка сбора событий технологического журнала и собранные данные

Рис. 7 Настройка сбора событий технологического журнала и собранные данные

Анализ —вторая итерация

Собранные данные также были обработаны скриптами. В топе событий SDBL оказались видны длительные события, связанные с выполнением запросов с RLS (рис. 8, 9).

Рис. 8 Топ событий SDBL по длительности и скрипт, которым он был получен

Рис. 8 Топ событий SDBL по длительности и скрипт, которым он был получен

Рис. 9 Топ событий SDBL по длительности (продолжение)

Рис. 9 Топ событий SDBL по длительности (продолжение)

В сумме время самых длительных событий составляет около 13 сек, что покрывает большую часть длительности серверного вызова. Заметно, что тексты запросов в модели SDBL гораздо меньше текстов соответствующих SQL-запросов.

Первый запрос из топа занимает в модели SDBL 409 строк, размер — 22,4 КБ. Текст SQL превосходит текст SDBL более чем в 8 раз по количеству строк и более чем в 11 раз по объему. Длительность события SDBL превышает длительность SQL-запроса более чем в 6 раз (рис. 10, сравните с рис. 6).

Рис. 10 Количество строк и размер текста самого длительного события SDBL

Рис. 10 Количество строк и размер текста самого длительного события SDBL

Уменьшение времени на первое открытие формы документа «Интерес»

  1. Все обнаруженные данные указывают на то, что при выполнении сложных запросов с RLS при первом открытии формы платформа может тратить значительные ресурсы на компиляцию текстов запросов.
  2. В связи с этим, мы проанализировали возможность перевода запросов с RLS в привилегированный режим и отказа от тяжелых динамических списков в пользу таблиц значений, заполняемых также в привилегированном режиме.
  3. Это оказалось возможным по бизнес-логике. Результат - время первого открытия формы с ограниченными правами стало таким же, как и с полными — 3,5 сек (рис. 11).

    Рис. 11 Результат оптимизации

    Рис. 11 Результат оптимизации

  4. Понимая связанные с RLS проблемы производительности, фирма 1С в свежих версиях своих решений разработала «Производительный» режим работы ограничений доступа на уровне записей. В этом режиме RLS работают в несколько раз быстрее. В случае проблем с RLS мы рекомендуем обновляться на последние версии программ и включать этот режим.
  5. В последних версиях УТиВСК 3 была серьезно переработана форма документа «Интерес». Отказались от множества таблиц на ней, и вместо них была сделана красивая HTML-лента связанных с интересом событий, добавлены удобные отборы и средства для быстрого ввода событий. Тем самым, было улучшено удобство работы без ущерба для производительности.

Еще статьи по теме медленного открытия форм и замедления работы «1С»:

Авторы статьи

Просянник Александр
Просянник Александр
Черанев Андрей
Черанев Андрей
Есть вопросы по статье? Задайте их нам!
info-big
Рассылка «Новости компании»: узнавайте о новых продуктах, услугах и спецпредложениях
Отправляя эту форму, Вы соглашаетесь с Политикой конфиденциальности и даете согласие на обработку персональных данных компанией «1С-Рарус»

Остались вопросы?
Нужна консультация?
Свяжитесь с нами!