Многие технические специалисты, переходя на новые версии платформы 1С (начиная с 8.3.14 и выше, включая 8.3.18), сталкиваются с неприятным сюрпризом: включение параметра /debug на сервере приводит к катастрофическому падению производительности. Особенно это заметно на тяжелых отчетах, которые могут формироваться в 4–5 раз медленнее, чем в обычном режиме. При этом на старых версиях, таких как 8.3.10, подобного эффекта не наблюдалось.
В рамках этой статьи мы подробно разберем, почему так происходит, проанализируем технические изменения в архитектуре платформы и найдем способы минимизировать это замедление, сохранив возможность отладки для разработчиков.
Давайте выясним первопричину. В старых версиях платформы (до 8.3.14) для отладки использовался протокол TCP. Он работал напрямую и обладал минимальными накладными расходами. Однако современная стратегия 1С направлена на работу через интернет и облачные сервисы, поэтому произошел переход на протокол HTTP.
Рассмотрим, к чему это привело. Теперь при каждой операции, даже если точка останова не установлена, сервер 1С обменивается данными с сервером отладки (dbgs) по протоколу HTTP. Это подразумевает:
XML или JSON.Эти микрозадержки на каждой строке кода в сумме дают тот самый эффект замедления в несколько раз, особенно в циклах или при обработке больших массивов данных в отчетах.
Проанализируем ситуацию с отчетами. В платформе 8.3.18 механизмы Системы компоновки данных (СКД) при включенном флаге /debug работают в особом режиме. Платформа начинает собирать расширенную информацию о выполнении запросов и компоновке макета, чтобы разработчик мог в любой момент «заглянуть» внутрь процесса формирования отчета.
Даже если программист не подключен к сеансу в данный момент, серверная часть, запущенная с ключом отладки, все равно выполняет эту подготовительную работу для всех пользователей без исключения. Именно поэтому пользователи начинают жаловаться на скорость работы системы сразу после перезапуска службы 1С с параметром -debug.
Разберем, как ведут себя фоновые задания. Начиная с версии 8.3.18, механизм перехвата фоновых заданий стал более «агрессивным». Если в настройках отладчика включен автоматический поиск и подключение фоновых заданий, платформа принудительно переводит их выполнение в режим, максимально удобный для отладки. Это часто отключает некоторые оптимизации параллельного выполнения, что еще сильнее нагружает процессор (CPU) и замедляет выполнение регламентных операций.
Посмотрим на интересный нюанс, упомянутый в практике. Часто системные администраторы замечают, что даже если в настройках клиентского приложения (Главное меню -> Сервис -> Параметры) отладка запрещена, сеанс все равно виден в списке предметов отладки на сервере.
Важно понимать: Флаг /debug в строке запуска службы сервера — это глобальное разрешение. Пользовательские настройки в клиенте лишь говорят о том, будет ли конфигуратор пытаться «подцепиться» к сеансу. Сам же сервер, видя флаг -debug, начинает готовить отладочную информацию для каждого запущенного процесса rphost. Чтобы полностью исключить влияние на пользователей, отладку нужно отключать именно на уровне службы сервера, а не в настройках клиента.
Рассмотрим несколько вариантов решения проблемы, от простых организационных до глубоких технических настроек.
Вместо того чтобы заставлять основной процесс сервера выполнять функции диспетчера отладки, мы можем вынести службу отладки в отдельный процесс. Это делается с помощью параметра -debug -debuggerURL. Посмотрите на пример настройки строки запуска:
"C:\Program Files\1cv8\8.3.18.1779\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\SRVINFO" -debug -debuggerURL http://localhost:1550
В этом случае необходимо отдельно запустить процесс dbgs.exe, который будет слушать порт 1550. Это снижает нагрузку на основные рабочие процессы rphost и помогает избежать «фризов» всей системы при активной работе программиста.
В некоторых сборках 8.3.18 помогает использование скрытых параметров для управления тем, как платформа подготавливает значения переменных. Если вы используете технологический журнал, вы можете заметить, что огромное количество времени тратится на отрисовку (рендеринг) значений сложных объектов для передачи в отладчик.
Выясним, в каких версиях ситуация стала лучше. Компания 1С признала проблемы с производительностью HTTP-отладки и внесла ряд оптимизаций в последующих обновлениях:
Проанализируем ситуацию: отладка на «проде» в современных реалиях 1С — это крайняя мера. Самый эффективный способ вернуть скорость пользователям — это выключить /debug в продуктивной базе. Для отладки сложных случаев лучше использовать:
Мы выяснили, что замедление в 4–5 раз на платформе 8.3.18 при включенной отладке — это не случайная ошибка, а следствие изменения архитектуры взаимодействия (переход на HTTP). Основные рекомендации сводятся к обновлению платформы до последних патчей ветки 8.3.18 или переходу на более новые версии, а также к выносу сервера отладки в отдельный процесс. Помните, что включенный режим /debug на рабочем сервере влияет на всех пользователей, независимо от их индивидуальных настроек в 1С:Предприятии.