При обновлении технологической платформы 1С:Предприятие с версии 8.3.11 на более свежие релизы, такие как 8.3.12 и 8.3.13, многие специалисты сталкиваются с необъяснимым на первый взгляд снижением быстродействия. Это проявляется в замедлении запуска отладки, долгой загрузке данных через XML и существенном падении скорости выполнения стандартных методов встроенного языка. В этой статье мы подробно проанализируем причины таких аномалий и разберем шаги по оптимизации системы.
Рассмотрим ситуацию, когда идентичный код на одной и той же базе данных показывает двукратную разницу в скорости выполнения. Проанализируем замеры производительности, предоставленные пользователями. Особенно ярко проблема проявляется при работе с таблицами значений. Выясним причину, изучив фрагмент кода, связанный с методом Свернуть:
// Пример проблемной операции в версии 8.3.12
ТЗ.Свернуть("НСИ,КСГ,Диагноз,ДиагнозДоп,ДиагнозДоп1,ПростаяМедицинскаяУслуга,ВозрастнаяКатегория,Пол,Профиль,КатегорияДлительности,ВидСтационара,ДКК");
По результатам замеров, на платформе 8.3.11 выполнение этой строки занимало около 0,59 сек., тогда как на версии 8.3.12 время увеличилось до 243,7 сек. Это замедление более чем в 400 раз! Аналогичная ситуация наблюдается и при записи объектов (СпрОбъект.Записать()), где время выполнения может увеличиваться почти вдвое. Посмотрим на статистику вызовов функции завершения:
// Замер времени завершения серверной функции
// Платформа 8.3.11: 2,278659 сек.
// Платформа 8.3.12: 4,633021 сек.
КонецФункции
Разберем, почему метод Свернуть стал работать медленнее. Начиная с версии 8.3.12, разработчики 1С внесли изменения во внутренние механизмы хеширования и сравнения данных. Это было необходимо для подготовки платформы к полноценной поддержке 64-битных вычислений и повышения стабильности при работе с огромными массивами данных. Однако в первых релизах ветки 8.3.12 этот механизм привел к деградации скорости обработки таблиц в оперативной памяти, особенно если в таблице много колонок с различными типами данных.
Рекомендация: Проверьте версию вашей платформы. Если вы используете ранние релизы 8.3.12, рассмотрите возможность перехода на последние патчи этой ветки или сразу на 8.3.14 и выше, где алгоритмы работы с коллекциями были дополнительно оптимизированы.
Одной из причин медленного запуска отладки и первого открытия форм является изменение механизма работы с глобальным кешем метаданных. В новых версиях платформы (начиная с 8.3.12) процесс десериализации метаданных при первом обращении стал более ресурсоемким. Платформа тратит значительное время на формирование общего кеша между рабочими процессами rphost.
Как показывает практика, решение часто кроется в настройках отладки. Рассмотрим интересный нюанс: в некоторых случаях включение режима отладки позволяет платформе использовать другие алгоритмы инициализации, что парадоксальным образом может ускорить работу в определенных сценариях за счет иного управления кешем.
Проанализируем сетевую составляющую. В платформе 8.3.12 был изменен приоритет использования сетевых протоколов. Система начала активнее пытаться использовать IPv6 для связи между компонентами кластера. Если в вашей операционной системе протокол IPv6 включен, но сетевое оборудование или DNS настроены некорректно, возникают скрытые таймауты. Платформа ждет ответа по IPv6, не получает его и только потом переключается на IPv4.
Чтобы исключить это влияние, выполним следующие действия:
IPv6 в свойствах сетевого адаптера на сервере 1С и сервере БД.hosts жестко пропишите соответствие имен серверов и их IP-адресов.DNS, чтобы разрешение имен происходило мгновенно.Выясним, как настройки железа влияют на новую платформу. Замечено, что версии 8.3.12 и выше более чувствительны к частоте процессора и его динамическому изменению. Если сервер работает в режиме "Сбалансированный" (Balanced), планировщик ОС может не успевать поднимать частоту ядер (Turbo Boost) при коротких, но интенсивных операциях 1С, таких как парсинг XML.
Что нужно сделать:
BIOS/UEFI сервера отключите все функции энергосбережения (C-States, P-States).Разберем влияние протокола отладки. В новых версиях 1С активно внедряется отладка по протоколу HTTP. В отличие от старого TCP-протокола, HTTP создает дополнительные накладные расходы на передачу пакетов. Если при запуске конфигуратора у вас включена отладка через HTTP, это может визуально замедлять выполнение кода в режиме отладки в 2-3 раза.
Для восстановления производительности в процессе разработки попробуйте переключиться обратно на TCP-отладку в настройках параметров запуска или в настройках сервера 1С.
Падение производительности при апгрейде платформы — это комплексная проблема, которая редко решается одним действием. Рассмотрим краткий чек-лист для восстановления скорости работы:
IPv6 и проверьте корректность разрешения имен серверов.Свернуть и Записать в критических узлах кода.HTTP/TCP).Следование этим шагам позволит вам не только вернуть производительность к уровню 8.3.11, но и в ряде случаев превзойти её за счет более современных механизмов новых версий платформы.