После обновления технологической платформы 1С:Предприятие на версии ветки 8.3.24 или 8.3.25 системные администраторы и разработчики часто сталкиваются со специфической проблемой: управляемые формы в конфигурациях с обычным интерфейсом (например, УТ 10.3 или доработанные старые версии БП 2.0) начинают открываться крайне медленно. Задержка может составлять от 30 секунд до минуты, при этом отладчик не фиксирует выполнения кода в этот момент, так как тормоза возникают до события ПриСозданииНаСервере.
В этой статье мы подробно разберем, почему это происходит, как проанализировать ситуацию с помощью технологического журнала и как правильно настроить инфраструктуру кластера, чтобы вернуть былую скорость работы системы.
Рассмотрим типичный сценарий: вы обновили платформу, чтобы соответствовать требованиям новых релизов Бухгалтерии предприятия, но основная рабочая база (например, торговая) осталась на обычном приложении. Проанализируем характерные признаки проблемы:
ПриСозданииНаСервере) не срабатывает до окончания паузы.Выясним причину такого поведения. Поскольку очистка локального кэша пользователя обычно не дает результата, необходимо заглянуть "под капот" взаимодействия клиента и сервера.
Для поиска "невидимых" пауз воспользуемся инструментом Технологический журнал (ТЖ). Нам необходимо отследить сетевые события и работу протокола VRS. Создадим файл конфигурации logcfg.xml и разместим его в каталоге conf (по умолчанию C:\Program Files\1cv8\conf).
Разберем пример настройки ТЖ для отслеживания сетевых задержек:
<config xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\logs\network_issues" history="2">
<event>
<eq property="Name" value="VRSREQUEST"/>
</event>
<event>
<eq property="Name" value="VRSRESPONSE"/>
</event>
<event>
<eq property="Name" value="CONN"/>
</event>
<property name="all"/>
</log>
</config>
Проанализируем полученный лог. В проблемных случаях в журнале можно увидеть записи о "пингах" (статистике направления пинга), которые повторяются с определенной периодичностью, например, каждые 11 секунд:
45:29.473001-0,CONN,0,level=INFO,Txt='Ping direction statistics: address=192.168.1.102:1560,pingTimeout=60000,pingPeriod=12000,period=11000,packetsSent=1...'
45:40.460000-0,CONN,0,level=INFO,Txt='Ping direction statistics: address=192.168.1.102:1560,pingTimeout=60000,pingPeriod=12000,period=11000,packetsSent=1...'
Эти записи указывают на то, что клиент пытается установить или подтвердить соединение с сервером для работы с управляемым интерфейсом, но получает ответ с огромной задержкой. Именно суммарное время этих неудачных или затянувшихся попыток связи и составляет ту самую минуту ожидания.
Одной из самых коварных причин задержек на платформе 8.3.25 является неоднородность версий компонентов 1С внутри одного кластера или сети. Проанализируем логи сервера (события EXCP), где может встретиться критически важная информация:
Различаются версии клиента и сервера (8.3.25.1560 - 8.3.24.1758), клиентское приложение: ragent
Это происходит, если в вашей инфраструктуре используется несколько серверов. Например:
При открытии управляемой формы в обычном приложении платформа инициирует дополнительные проверки метаданных и лицензий. Если ragent (агент сервера) на разных узлах имеет разные версии, механизмы внутреннего пинга и синхронизации начинают работать некорректно, вызывая таймауты. Решение здесь одно: строгое приведение всех служб 1C:Enterprise Server на всех серверах кластера к идентичному номеру сборки.
Рассмотрим еще одну причину, характерную для новых версий платформы. Начиная с 8.3.24, 1С изменила механизмы работы с сетевыми адресами. Если на сервере или клиентской машине включен протокол IPv6, но сетевая инфраструктура настроена на него некорректно, платформа может пытаться сначала достучаться до сервера по IPv6, ждать таймаута и только потом переходить на IPv4.
Разберем, как это исправить:
hosts явно пропишите соответствие IP-адреса сервера его имени, чтобы исключить задержки на уровне DNS.Иногда после обновления платформы или "динамического" обновления конфигурации (так называемого "демонического") кэш управляемых форм на стороне сервера оказывается поврежденным. Обычная очистка папок в %AppData% у пользователя в этом случае не поможет.
Выполним глубокую очистку серверного кэша:
1C:Enterprise Server.C:\Program Files\1cv8\srvinfo).reg_) и внутри нее удалите содержимое папок snccntx (сеансовые данные) и configsave.srvinfo.Управляемые формы в 1С отрисовываются с помощью встроенного движка на базе WebKit (Chromium в последних версиях). В обычном приложении этот движок работает внутри контейнера. Если на сервере (в случае работы через RDP) или на клиенте установлены устаревшие драйверы видеокарты или включено аппаратное ускорение, которое конфликтует с платформой, отрисовка формы может "подвисать".
Для проверки этой гипотезы можно попробовать запустить 1С с параметром /NoProxy или изменить настройки в conf.cfg, отключив аппаратное ускорение отрисовки, хотя этот метод чаще помогает при визуальных артефактах, он также может влиять на скорость инициализации контейнера формы.
Подводя итог, отметим, что в большинстве случаев проблема "минутного" ожидания на платформе 8.3.25 решается именно синхронизацией версий всех компонентов кластера. Платформа стала крайне чувствительна к сетевым задержкам и несоответствию версий между агентами сервера, лицензирующими узлами и клиентскими приложениями.