Накопленные вызовы в 1С: что это и как с ними работать

Накопленные вызовы в 1С — это суммарный счётчик обращений клиентского приложения к серверу 1С:Предприятия за время работы сеанса или выполнения конкретного действия. Каждый раз, когда клиентский код запрашивает данные, выполняет серверную процедуру или обращается к реквизиту объекта через «точку», счётчик увеличивается. Чем больше таких обращений, тем медленнее работает программа, особенно в клиент-серверном режиме и при работе через интернет.

Механизм накопления вызовов напрямую связан с архитектурой «клиент — сервер». Тонкий клиент и веб-клиент не хранят данные локально: любая операция с базой требует сетевого обмена. Если форма обращается к серверу сотни раз при открытии, пользователь видит «подвисание», а администратор — рост нагрузки на сервер приложений и СУБД.

Разработчики и администраторы используют показатель накопленных вызовов как диагностический инструмент: он помогает найти «тяжёлые» формы, неоптимальный код в циклах и лишние серверные процедуры. Ниже разберём, где смотреть этот показатель, что считается проблемой и как сократить число вызовов без риска для данных.

Что именно считается накопленным вызовом

Вызов сервера фиксируется в нескольких типичных ситуациях. Первая — явный вызов серверной процедуры или функции из клиентского модуля, помеченной директивой &НаСервере. Вторая — неявный вызов: обращение к реквизиту объекта, табличной части или связанным данным через точку на клиенте, когда платформа вынуждена дозапросить данные с сервера. Третья — интерактивные действия пользователя: запись документа, проведение, заполнение формы, пересчёт итогов.

Важно понимать, что один «вызов» — это один сетевой обмен между клиентом и сервером, а не одно действие пользователя. Нажатие одной кнопки может породить десятки вызовов, если код написан неоптимально. Поэтому накопленное значение за сеанс у активного пользователя легко достигает тысяч и десятков тысяч.

Где посмотреть количество накопленных вызовов

Основной инструмент — замер производительности в конфигураторе (меню «Отладка» — «Замер производительности»). Он показывает, сколько раз вызывалась каждая строка кода и сколько времени она заняла, включая серверные вызовы. Для анализа интерактивной работы замер включают в режиме 1С:Предприятие через параметр командной строки или настройку запуска из конфигуратора.

Второй источник — технологический журнал с событием CALL. Он фиксирует каждый вызов сервера с указанием длительности и контекста. Этот способ подходит для серверного анализа, когда нужно собрать статистику по всем пользователям, а не по одному сеансу.

1. 1
   Откройте конфигуратор и включите замер производительности перед воспроизведением проблемы.
2. 2
   В режиме 1С:Предприятие выполните действие, которое работает медленно (открытие формы, проведение документа).
3. 3
   Остановите замер и отсортируйте строки по количеству вызовов и длительности.
4. 4
   Найдите строки с аномально большим числом вызовов внутри циклов — это первичные кандидаты на оптимизацию.

Какие признаки указывают на проблему с вызовами

Единой «нормы» количества вызовов не существует: она зависит от конфигурации, канала связи и сценария работы. Ориентироваться стоит на симптомы и сравнение: если одна форма открывается заметно дольше аналогичных, а замер показывает сотни серверных вызовов там, где у соседних форм их десятки — проблема локализована.

Основные причины большого числа вызовов

Обращения к данным через «точку» на клиенте

Конструкция вида Строка.Товар.Наименование в клиентском коде заставляет платформа дозапрашивать данные с сервера при каждом обращении. В цикле по табличной части из ста строк это даёт сотни вызовов. Решение — получить все нужные данные одним запросом на сервере и вернуть на клиент готовую структуру.

Вызов серверных процедур в цикле

Если серверная процедура вызывается из клиентского цикла, каждая итерация — отдельный сетевой обмен с накладными расходами на сериализацию параметров. Правильный подход — передать весь массив данных в один серверный вызов, обработать его целиком на сервере и вернуть результат.

Избыточные обновления и пересчёты формы

Программное обновление формы, повторное чтение объекта после каждого изменения, лишние обработчики ожидания также накапливают вызовы. Такие проблемы видны в замере как повторяющиеся одинаковые строки с большим счётчиком.

Как сократить накопленные вызовы: практические приёмы

Главный принцип — «толстые» серверные вызовы вместо множества «тонких». Один вызов, передающий пакет данных и выполняющий запрос на сервере, почти всегда быстрее сотни мелких обращений, даже если суммарный объём кода вырос. Особенно это заметно на медленных каналах, где доминирует сетевая задержка.

Второй приём — кэширование на клиенте. Данные, которые не меняются в течение сеанса (настройки, значения констант, редко изменяемые справочники), разумно получать один раз и хранить в переменных модуля или через механизм повторного использования возвращаемых значений.

Третий приём — пересмотр состава формы. Убирайте с формы неиспользуемые динамические списки, лишние реквизиты связанных объектов и автоматические обновления там, где они не нужны пользователю для работы.

Сравнение подходов

Много мелких вызовов с клиента

Просто писать код, но каждый вызов несёт сетевые накладные расходы; неприемлемо в циклах и на медленных каналах.

Один пакетный серверный вызов

Требует переработки кода и передачи структур данных, зато радикально снижает число обращений и время выполнения.

Кэширование на клиенте

Подходит для редко меняющихся данных; ограничение — риск работы с устаревшими значениями, нужен контроль актуальности.

Риски и границы самостоятельной оптимизации

Оптимизация вызовов — это изменение прикладного кода, а значит, она способна нарушить учётную логику. Опаснее всего переносить проведение документов и расчёт итогов без понимания транзакционной модели: потеря блокировок или изменение порядка записи приводит к расхождению данных, которое трудно диагностировать.

Безопасная зона самостоятельной работы — замеры, анализ техножурнала и оптимизация интерфейсных механизмов (состав форм, кэширование настроек). Изменение серверной бизнес-логики в типовой конфигурации лучше согласовывать с разработчиком, а перед любыми правками делать выгрузку базы.

Как проверить результат оптимизации

Проверка строится на сопоставлении «до» и «после» в одинаковых условиях: та же база, тот же документ, тот же клиент. Сравнивайте не только число вызовов, но и время выполнения операции и корректность результата — сформированные движения документа, итоги отчётов.

Контрольные точки

Как проверить результат

Число вызовов в замере на целевой операции

Норма

Снизилось в разы при той же функциональности

Тревожный признак

Не изменилось или снизилось за счёт потери функциональности

Время открытия формы у пользователя

Норма

Заметно быстрее, особенно у удалённых клиентов

Тревожный признак

Ускорение видно только в замере, но не в реальной работе

Результат проведения и отчёты

Норма

Движения и итоги совпадают с данными до изменений

Тревожный признак

Есть расхождения — откатывайте изменения

Если после оптимизации число вызовов упало, а скорость не выросла, узкое место находится в другом: запросах к СУБД, блокировках или ресурсах сервера. В этом случае анализ продолжают по длительным событиям техножурнала — DBMSSQL, SDBL, EXCP.

Частые вопросы

Накопленные вызовы влияют на работу других пользователей?

Косвенно — да. Каждый вызов занимает ресурсы сервера приложений и соединение с СУБД. Если многие сеансы генерируют избыточные вызовы, растёт общая нагрузка, и замедление почувствуют все пользователи, а не только автор «тяжёлой» операции.

Можно ли обнулить или отключить счётчик накопленных вызовов?

Это диагностический показатель, а не настройка. Его нельзя «отключить» в прикладном решении: платформа фиксирует обращения автоматически. Счётчик сеанса обнуляется естественным образом при новом подключении; влиять нужно не на счётчик, а на код, который порождает вызовы.

Почему в файловом режиме проблема с вызовами не заметна?

В файловом режиме обмен идёт внутри одного компьютера или по локальной сети к общему файлу, сетевая задержка минимальна, и стоимость каждого вызова мала. При переходе на клиент-серверный режим или работу через интернет та же неоптимальная логика начинает ощутимо тормозить.

Что лучше для диагностики: замер производительности или техножурнал?

Они дополняют друг друга. Замер удобнее для поиска конкретной строки кода в отдельном сеансе, техножурнал — для сбора статистики по всем пользователям и серверным процессам. На практике начинают с замера проблемного действия, а техножурнал подключают, когда проблема плавающая или массовая.

Нужно ли сокращать вызовы, если программа работает быстро?

Нет. Оптимизация оправдана только при реальных симптомах: медленных формах, жалобах пользователей, росте нагрузки на сервер. Преждевременная переработка работающего кода добавляет риски без ощутимой выгоды.

Поможет ли снижению вызовов переход на тонкий клиент вместо толстого?

Тонкий клиент сам по себе не уменьшает число вызовов — он лишь передаёт меньше данных за один обмен. Если код содержит обращения в цикле, проблема сохранится. Сначала оптимизируют код, а выбор клиента рассматривают как дополнительную меру.