← На главную
При анализе клиентского замера производительности разработчики часто сталкиваются с ситуацией, когда до 90–95% времени выполнения уходит на одну-единственную строку с вызовом метода ОткрытьФорму. При этом замер серверных процедур формы (например, ПриСозданииНаСервере) не показывает значительных задержек. Ситуация усугубляется, когда форма начинает зависать только у отдельных пользователей, в то время как у остальных открывается штатно.
Разберем детально, какие процессы скрываются внутри клиентского вызова открытия формы, почему тормозят динамические списки и как локализовать проблему.
Что входит в длительность выполнения ОткрытьФорму
Клиентский замер производительности на строке ОткрытьФорму аккумулирует не только исполнение видимого серверного кода, но и целый комплекс системных операций:
- Скрытые серверные события: инициализация контекста формы, вызовы
ПриЗагрузкеПользовательскихНастроекНаСервере, ПриЧтенииНаСервере, расчет прав на команды и построение командного интерфейса. - Сериализация и сетевая передача: упаковка структуры формы, значений реквизитов и метаданных в сетевые пакеты, их передача по локальной сети или RDP-каналу и последующая десериализация на клиенте.
- Формирование первого пакета динамического списка: трансляция запроса динамического списка в SQL, наложение условий RLS (ограничения доступа на уровне записей) и получение первой порции строк.
- Клиентский рендеринг: отрисовка элементов управления графической подсистемой операционной системы. При наличии сотен динамически создаваемых элементов этот этап может вызывать ощутимый фриз интерфейса.
Особенности динамического списка: мифы и реальность
Распространено заблуждение, что динамический список при отсутствии фильтров считывает всю таблицу базы данных целиком. На уровне платформы 1С динамический список по умолчанию считывает порцию данных (обычно порядка 45 строк), необходимую для заполнения видимой области таблицы на экране.
Однако динамическое считывание перестает работать эффективно в следующих случаях:
- Сортировка по неиндексированным полям: если пользователь или конфигурация применяет сортировку по реквизиту, не входящему в индекс (например, по реквизиту составного типа, комментарию или полю из левого соединения), СУБД вынуждена просканировать всю таблицу для упорядочивания данных перед тем, как отдать первые 45 строк.
- Конструкции группировки и устранения дублей: наличие операторов
ВЫБРАТЬ РАЗЛИЧНЫЕ, СГРУППИРОВАТЬ ПО или ИТОГИ в тексте запроса динамического списка заставляет СУБД предварительно рассчитать весь объем данных во временных таблицах памяти. - Отсутствие свойства «Основная таблица»: если для произвольного запроса не указана основная таблица, платформа лишается возможности строить быстрые критериальные выборки по первичному ключу (ссылке).
- Пользовательские группировки колонок: если пользователь настроил группировку строк в списке (преобразовал список в иерархическое дерево), динамическое постраничное считывание отключается — СУБД считывает всю выборку для построения иерархии.
Почему форма зависает у одного конкретного пользователя
Если в одинаковых условиях терминального сервера у одних пользователей форма открывается быстро, а у других «намертво» виснет, проанализируем следующие индивидуальные факторы:
- Пользовательские настройки формы: пользователь мог случайно установить сортировку по сложной составной колонке, включить группировку строк или наложить ресурсоемкий отбор (например, поиск по подстроке через условие «содержит» по неиндексированному полю). Для проверки достаточно сбросить пользовательские настройки формы через раздел администрирования настроек пользователей.
- Повреждение локального кэша тонкого клиента: файлы кэша конфигурации и пользовательских данных (каталоги
%AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8) могут содержать поврежденные схемы форм. Пересоздание пользователя операционной системы или ручная очистка указанных каталогов решает эту проблему. - Очереди расчета ключей доступа RLS: в типовых конфигурациях (1С:ERP, КА, УТ) ограничение прав строится на ключах доступа. Если по конкретному пользователю идут фоновые перерасчеты прав или повреждены записи в регистрах ключей доступа, запрос динамического списка под его учетной записью обрастает тяжелыми проверками в СУБД.
Программное создание элементов и оформление данных
Проанализируем влияние программного кода на этапе создания формы:
- Программное добавление реквизитов формы: массовое использование метода
ИзменитьРеквизиты в событии ПриСозданииНаСервере приводит к полной переинициализации контекста формы, что кратно увеличивает время серверного вызова. - Оформление строк списка: если для вывода дополнительных сведений используются тяжелые запросы или логика в серверных событиях, целесообразно переходить на типовые механизмы обработки и оформления данных динамического списка, минимизируя лишние серверные вызовы.
План действий по диагностике и устранению проблемы
Выполним пошаговую локализацию узкого места:
- Сбросим настройки пользователя: очистим сохраненные настройки проблемной формы у конкретного пользователя через меню «Администрирование — Настройки пользователей и прав — Очистка настроек».
- Очистим кэш клиента: удалим временные файлы тонкого клиента в профиле пользователя.
- Проверим замер на сервере: запустим отладчик с замером производительности строго со стороны сервера, чтобы исключить задержки сетевой сериализации и графической отрисовки.
- Проанализируем индексы динамического списка: убедимся, что по всем полям, доступным для стандартной сортировки и отборов, в метаданных установлены свойства Индексировать или Индексировать с доп. упорядочиванием.
- Подключим Технологический журнал: настроим сбор событий
DBMSSQL / DBPOSTGRS с фильтром по длительности (Duration > 1000000), чтобы увидеть реальный сгенерированный SQL-запрос динамического списка с учетом наложенных условий RLS и оценить план его выполнения в СУБД.