Часто разработчики сталкиваются с ситуацией, когда длительная операция (например, формирование заказов поставщикам или сложный расчет себестоимости) занимает 20–30 минут, но при запуске замера производительности суммарное время выполнения всех строк кода составляет всего пару минут. Возникает закономерный вопрос: куда исчезает остальное время и чем занята система? В этой статье мы подробно разберем, как правильно интерпретировать данные замера, настроить отладку фоновых заданий и выявить скрытые «узкие места».
Первым делом проанализируем, как 1С считает время в окне замера производительности. В платформе существует критически важная настройка: «Для вызовов процедур и функций включать время выполнения». Рассмотрим подробнее, на что она влияет.
Если этот флажок снят, система фиксирует только «чистое время» выполнения конкретных операторов в строке. Если в строке кода вызывается функция, которая работает 10 минут, но сама строка просто присваивает результат переменной, замер покажет ничтожно малое время. Выполнение вызванной функции будет учтено отдельно в ее собственном теле кода. Это удобно для поиска конкретной «тяжелой» строки, но мешает видеть общую картину.
Если флажок установлен, время выполнения строки будет включать в себя время всех вложенных вызовов. Для комплексного анализа рекомендуется всегда включать эту опцию, чтобы сразу видеть, какой метод верхнего уровня «пожирает» ресурсы. Выясним причину расхождений в результатах: если замер все равно показывает мало времени, значит, код исполняется где-то, куда замер «не дотягивается».
В современных конфигурациях (на управляемых формах) тяжелые расчеты часто выносятся в фоновые задания (длительные операции). Стандартный замер производительности, запущенный в клиентском сеансе, не видит того, что происходит внутри серверного фонового процесса. Проанализируем ситуацию: если в коде встречается вызов ДлительныеОперации.ЗапуститьВыполнениеНаСервере(), основной поток просто ждет завершения или периодически опрашивает статус, а реальная работа идет в другом сеансе.
Чтобы выполнить замер производительности фонового задания, выполним следующие шаги:
-debug. Без этого замер на стороне сервера будет невозможен.Иногда время «пропадает» в момент перехода управления с клиента на сервер и обратно. Рассмотрим ситуацию: у вас есть обработка с огромной таблицей значений на форме. При вызове серверного метода &НаСервере платформа должна передать всё состояние формы (весь контекст) на сервер. Если данных много (десятки тысяч строк), процесс сериализации (превращения данных в XML/Binary для передачи по сети) может занимать минуты. Это время не отображается в замере производительности кода, так как оно затрачивается самой платформой 1С между строками вызова.
Для решения этой проблемы проанализируем возможность использования внеконтекстных вызовов:
&НаСервереБезКонтекста
Процедура ОбработатьДанныеНаСервере(МассивСсылок)
// Здесь передается только массив ссылок, а не вся форма.
// Это работает в разы быстрее.
КонецПроцедуры
Всегда старайтесь минимизировать объем данных, передаваемых между клиентом и сервером. Используйте &НаСервереБезКонтекста везде, где не требуется прямое изменение реквизитов формы «на лету».
Если замер показывает, что 1С тратит много времени на одну строку (например, поиск в таблице значений), следует обратить внимание на алгоритм поиска. Рассмотрим пример из практики: поиск в таблице из 3000 строк внутри цикла. Если делать это обычным перебором, время выполнения будет расти в геометрической прогрессии.
Посмотрим на пример оптимизации с использованием индексов в ТаблицаЗначений:
// Вместо медленного поиска:
СтрокаНоменклатуры = Объект.Запасы.Найти(ИскомыйТовар, "Номенклатура");
// Используем индексацию для ускорения:
ТаблицаЗапасов = Объект.Запасы.Выгрузить();
ТаблицаЗапасов.Индексы.Добавить("Номенклатура");
ПараметрыОтбора = Новый Структура("Номенклатура", ИскомыйТовар);
НайденныеСтроки = ТаблицаЗапасов.НайтиСтроки(ПараметрыОтбора);
Еще более эффективный метод для многократного поиска — использование объекта Соответствие. Проанализируем пример:
КэшЗапасов = Новый Соответствие;
Для Каждого Стр Из Объект.Запасы Цикл
КэшЗапасов.Вставить(Стр.Номенклатура, Стр);
КонецЦикла;
// Теперь поиск выполняется мгновенно
НужнаяСтрока = КэшЗапасов.Получить(ИскомыйТовар);
Когда штатный замер не дает ответов (например, при подозрениях на блокировки базы данных или проблемы на уровне СУБД), на помощь приходит Технологический журнал (ТЖ). Это мощный инструмент, который фиксирует события на уровне платформы.
Разберем основные события ТЖ, которые помогут найти «потерянное» время:
Для долгосрочного мониторинга и понимания того, как операцию видит пользователь, рекомендуется внедрить механизм APDEX (Оценка производительности). В типовых конфигурациях 1С (УТ 11, ERP, КА) этот функционал уже встроен. Мы можем замерить время от момента нажатия кнопки до момента появления результата на экране. Это даст объективную картину, включая все сетевые задержки, отрисовку интерфейса и фоновые процессы, которые не всегда улавливаются ручным замером в конфигураторе.
Подведем итог: если замер показывает «пустоту», проверьте фоновые задания, настройте автоматическое подключение отладчика и обратите внимание на объем данных, передаваемых между клиентом и сервером. Оптимизация алгоритмов поиска через Соответствие и индексацию таблиц часто позволяет сократить время работы обработки с десятков минут до нескольких секунд.