Почему код в 1С сначала работает быстро, а потом внезапно начинает тормозить?

Почему код в 1С сначала работает быстро, а потом внезапно начинает тормозить

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

Это одна из самых неприятных особенностей прикладной разработки на 1С.

• на тестовой базе всё летает;
• на небольшом объёме данных код выглядит адекватно;
• пользователи сначала ничего не замечают;
• доработка считается успешной.

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

Я сам несколько раз недооценивал такие вещи на старте, потому что на тестовой базе всё выглядело нормально. А потом на рабочем контуре внезапно выяснялось, что проблема была не в одном большом запросе, а в сотнях маленьких действий, которые по отдельности казались безобидными.

Именно поэтому самые неприятные проблемы производительности — не те, которые сразу падают с ошибкой, а те, которые долго маскируются под нормальную работу.

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

 

Почему "внезапно" — это иллюзия

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

• запрос в цикле на 10 строках почти незаметен;
• ПолучитьОбъект() 5 раз в день — тоже не трагедия;
• тяжёлая логика в ПриОткрытии() на пустой базе работает терпимо;
• запись объектов по одному в обработке на 100 элементов не выглядит проблемой.

Но потом происходит одно или сразу несколько событий:

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

И здесь кроется главный подвох: код не обязательно был неправильным с самого начала. Он просто не был рассчитан на рост нагрузки.

 

1. Запрос в цикле: работает, пока строк мало

Это самый известный антипаттерн, но именно из-за своей привычности он особенно опасен.

 

Как обычно выглядит

Для каждого СтрокаТоваров Из ТаблицаТоваров Цикл
    
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ
    |   Остатки.Товар,
    |   Остатки.КоличествоОстаток КАК Количество
    |ИЗ
    |   РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки
    |ГДЕ
    |   Остатки.Товар = &Товар";
    
    Запрос.УстановитьПараметр("Товар", СтрокаТоваров.Товар);
    
    РезультатЗапроса = Запрос.Выполнить();
    Выборка = РезультатЗапроса.Выбрать();
    
    Если Выборка.Следующий() Тогда
        СтрокаТоваров.Остаток = Выборка.Количество;
    Иначе
        СтрокаТоваров.Остаток = 0;
    КонецЕсли;
    
КонецЦикла;

 

Почему сначала всё нормально

Потому что на 10–20 строках это действительно может работать терпимо. Код простой, понятный, быстро пишется и легко отлаживается.

 

Почему потом становится плохо

Потому что количество обращений к базе данных растёт линейно вместе с количеством строк.

На 100 строках это уже заметно.
На 1 000 — неприятно.
На 10 000 — уже очень неприятно.

Разработчик видит обычный цикл и обычный запрос, но фактически получает сотни или тысячи отдельных обращений к СУБД. То есть проблема уже не в одном медленном запросе, а в массовом повторении одинакового действия.

 

Как лучше

По моему опыту здесь почти всегда выигрывает пакетный подход: один запрос на весь набор, а дальше разбор результата в памяти.

Запрос = Новый Запрос;
Запрос.Текст = 
"ВЫБРАТЬ
|   Товары.Товар КАК Товар,
|   ЕСТЬNULL(Остатки.КоличествоОстаток, 0) КАК Количество
|ИЗ
|   &ТаблицаТоваров КАК Товары
|       ЛЕВОЕ СОЕДИНЕНИЕ РегистрНакопления.ТоварыНаСкладах.Остатки КАК Остатки
|       ПО Товары.Товар = Остатки.Товар";

Запрос.УстановитьПараметр("ТаблицаТоваров", ТаблицаТоваров);

РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();

ОстаткиПоТоварам = Новый Соответствие;

Пока Выборка.Следующий() Цикл
    ОстаткиПоТоварам.Вставить(Выборка.Товар, Выборка.Количество);
КонецЦикла;

Для каждого СтрокаТоваров Из ТаблицаТоваров Цикл
    Если ОстаткиПоТоварам.СодержитКлюч(СтрокаТоваров.Товар) Тогда
        СтрокаТоваров.Остаток = ОстаткиПоТоварам[СтрокаТоваров.Товар];
    Иначе
        СтрокаТоваров.Остаток = 0;
    КонецЕсли;
КонецЦикла;

 

Когда простой вариант допустим

• элементов заведомо мало;
• код выполняется редко;
• упрощение логики важнее оптимизации.

Но важно, чтобы это было осознанное решение, а не привычка “ну так быстрее написать”.

 

2. Использование ПолучитьОбъект() без реальной необходимости

Вторая очень частая причина деградации — привычка получать объект там, где достаточно ссылки, выборки или запроса.

 

Как обычно бывает

Для каждого СтрокаДокументов Из ДокументыКОбработке Цикл
    
    ДокументОбъект = СтрокаДокументов.Ссылка.ПолучитьОбъект();
    
    Если ДокументОбъект.Проведен Тогда
        Продолжить;
    КонецЕсли;
    
    ДокументОбъект.Комментарий = "Обработан автоматически";
    ДокументОбъект.Записать();
    
КонецЦикла;

 

Почему сначала это не вызывает вопросов

Потому что с объектом удобно:

• все реквизиты под рукой;
• можно сразу менять данные;
• всё хорошо читается;
• удобно отлаживать.

На небольших объёмах это кажется хорошим вариантом.

 

Где начинается проблема

Вот здесь кроется главный подвох: ПолучитьОбъект() — это не "взять одно поле". Это полноценная загрузка объекта прикладного уровня со всей сопутствующей стоимостью.

Если в цикле тысячи ссылок, вы фактически:

• многократно читаете данные тяжелее, чем нужно;
• тратите память;
• замедляете массовую обработку;
• потенциально запускаете лишнюю прикладную логику.

По моему опыту очень много медленных обработок в 1С можно ускорить уже на одном вопросе: а точно ли здесь нужен объект?

 

Как лучше

Если задача — только проверить реквизит и отобрать данные, я бы первым делом посмотрел в сторону запроса.

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|   Документы.Ссылка,
|   Документы.Проведен,
|   Документы.Комментарий
|ИЗ
|   Документ.РеализацияТоваровУслуг КАК Документы
|ГДЕ
|   Документы.Ссылка В (&СписокСсылок)";

Запрос.УстановитьПараметр("СписокСсылок", СписокСсылок);

Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
    Если Выборка.Проведен Тогда
        Продолжить;
    КонецЕсли;
    
    ДокументОбъект = Выборка.Ссылка.ПолучитьОбъект();
    ДокументОбъект.Комментарий = "Обработан автоматически";
    ДокументОбъект.Записать();
КонецЦикла;

Здесь объект получаем только там, где без него действительно не обойтись.

 

Практическое правило

• если нужен один реквизит — сначала подумайте о запросе;
• если нужен набор данных — подумайте о выборке;
• если нужно изменение объекта с запуском бизнес-логики — тогда объект действительно нужен.

То есть вопрос должен быть не "можно ли получить объект?", а "зачем именно он нужен здесь?"

 

3. Запись объекта ради одного реквизита

Иногда проблема даже не в чтении, а в том, что объект массово записывается там, где это создаёт дорогой побочный эффект.

 

Типовой сценарий

Для каждого СтрокаСписка Из СписокЭлементов Цикл
    
    ЭлементОбъект = СтрокаСписка.Ссылка.ПолучитьОбъект();
    ЭлементОбъект.ПометкаОбработки = Истина;
    ЭлементОбъект.Записать();
    
КонецЦикла;

На первый взгляд всё просто: получили объект, изменили поле, записали.

 

Почему сначала не видно проблемы

Потому что на маленьком объёме это работает терпимо. Да, код понятный. Но это ещё не значит, что он дешёвый.

 

Почему потом всё ухудшается

Потому что запись объекта может тянуть за собой:

• проверки;
• подписки на события;
• пересчёты;
• запись движений;
• блокировки;
• журналирование;
• каскадную прикладную логику.

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

По моему мнению любой массовый код, который в цикле делает Записать(), должен сразу вызывать вопросы.

 

Что делать лучше

Варианты зависят от задачи, но я бы смотрел в такие стороны:

• заранее отобрать только действительно нужные объекты;
• не трогать то, что и так не требует изменения;
• разделять этап анализа и этап записи;
• переносить тяжёлую массовую обработку в фон;
• пересматривать саму модель хранения признака, если это частый сценарий.

Простейшее улучшение — хотя бы не открывать и не записывать всё подряд.

Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
|   СправочникОбъектов.Ссылка
|ИЗ
|   Справочник.Номенклатура КАК СправочникОбъектов
|ГДЕ
|   НЕ СправочникОбъектов.ПометкаОбработки
|   И СправочникОбъектов.ЭтоГруппа = ЛОЖЬ";

Выборка = Запрос.Выполнить().Выбрать();

Пока Выборка.Следующий() Цикл
    
    ЭлементОбъект = Выборка.Ссылка.ПолучитьОбъект();
    ЭлементОбъект.ПометкаОбработки = Истина;
    ЭлементОбъект.Записать();
    
КонецЦикла;

Да, массовая запись здесь остаётся. Но даже такой шаг уже заметно снижает лишнюю нагрузку.

 

Важный риск

Если начать "ускорять" запись, не понимая бизнес-логику объекта, можно сломать прикладной сценарий. Поэтому здесь я бы обязательно проверил:

• какие обработчики срабатывают;
• какие подписки подключены;
• какие регистры и механизмы завязаны на запись.

 

4. Тяжёлая логика в формах: пользователь чувствует это первым

Есть код, который тормозит фоновую обработку. А есть код, который тормозит ощущение от системы. Это логика в формах.

 

Как это обычно выглядит

В ПриОткрытии(), ПриСозданииНаСервере(), ПриИзменении() и похожих обработчиках постепенно накапливается логика:

• запросы;
• расчёты;
• проверки прав;
• заполнение списков;
• пересчёт зависимых полей;
• чтение остатков, цен, состояний;
• вызовы серверных процедур.

Условно это может выглядеть так:

&НаКлиенте
Процедура ПриОткрытии(Отказ)

    ЗаполнитьДоступныеСклады();
    ЗаполнитьЦены();
    ПроверитьДоступностьОстатков();
    ПересчитатьСуммы();
    ОбновитьСвязанныеДанные();

КонецПроцедуры

А каждая из этих процедур может внутри ещё сходить на сервер и выполнить несколько запросов.

 

Почему сначала это кажется удобным

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

 

Почему потом форма начинает "думать"

Потому что форма из интерфейса превращается в мини-сервер приложений.

И тогда пользователь открывает документ — и ждёт:

• загрузку данных;
• дополнительные серверные вызовы;
• расчёты;
• инициализацию служебной логики.

А если часть логики ещё и висит на ПриИзменении(), получаем повторные вызовы на каждое действие пользователя.

По моему опыту именно такие формы потом описывают фразой: "вообще-то всё работает, но как-то тяжело".

 

Как лучше

Я бы держал в голове несколько простых правил.

1. Не загружать в форму всё "на всякий случай"
Если данные не нужны в момент открытия — не надо тянуть их сразу.

2. Не смешивать UI и бизнес-логику
Форма должна инициировать действие, а не тащить на себе весь алгоритм.

3. Проверять число серверных вызовов
Особенно в управляемых формах.

4. Тяжёлые расчёты выносить
В общий модуль, команду, фоновое задание или отдельный сценарий.

 

Практический признак проблемы

Если форма открывается заметно дольше, чем ожидает пользователь, я бы первым делом посмотрел не только запросы, но и весь маршрут выполнения обработчиков формы.

 

5. Повторное чтение одних и тех же данных

Часто система тормозит не из-за одного большого запроса, а из-за большого числа маленьких одинаковых обращений.

 

Как бывает

Внутри одной процедуры или одного сценария многократно читаются одни и те же данные:

• настройки;
• константы;
• курсы валют;
• карточки контрагентов;
• связанные документы;
• параметры учётной политики.

Пример:

Для каждого СтрокаТоваров Из ТаблицаТоваров Цикл
    
    ВалютаУпрУчета = Константы.ВалютаУправленческогоУчета.Получить();
    Курс = ПолучитьКурсВалюты(ВалютаУпрУчета, ДатаДокумента);
    
    СтрокаТоваров.СуммаУпр = СтрокаТоваров.Сумма * Курс;
    
КонецЦикла;

 

Почему это долго незаметно

Потому что каждая операция сама по себе маленькая. И в этом как раз главная ловушка: отдельно — мелочь, в сумме — уже вязкость, задержки и ощущение “почему всё такое тяжёлое”.

 

Как лучше

Если данные не меняются в рамках алгоритма, я бы выносил их чтение за пределы цикла.

ВалютаУпрУчета = Константы.ВалютаУправленческогоУчета.Получить();
Курс = ПолучитьКурсВалюты(ВалютаУпрУчета, ДатаДокумента);

Для каждого СтрокаТоваров Из ТаблицаТоваров Цикл
    СтрокаТоваров.СуммаУпр = СтрокаТоваров.Сумма * Курс;
КонецЦикла;

Кроме того, полезно:

• кэшировать данные в рамках процедуры;
• переиспользовать результаты запроса;
• не вычислять повторно то, что не меняется по ходу выполнения.

Такой рефакторинг не выглядит эффектно. Это не “героическая оптимизация”. Но именно такие мелочи часто дают устойчивое ускорение без усложнения кода.

 

6. Обработка "по одному", когда нужна пакетная логика

Очень много медленных решений в 1С объединяет одна общая черта: они делают полезное действие по одному элементу, хотя задача давно просится на пакетную обработку.

 

Симптомы

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

 

Почему код кажется нормальным

Потому что он линейный и понятный:

1. взять элемент;
2. обработать;
3. записать;
4. перейти к следующему.

Такой код легко писать, легко читать и легко показывать на демонстрации.

 

Почему потом система не выдерживает

Потому что вы многократно повторяете:

• получение данных;
• прикладную и системную логику;
• обращения к БД;
• фиксации изменений;
• блокировки ресурсов.

И вот здесь начинается контраст между "понятно написано" и "хорошо работает". Это совсем не одно и то же.

 

Что лучше

По моему опыту здесь полезно думать пакетами:

• сначала отобрать всё нужное;
• затем получить необходимые данные одним или несколькими запросами;
• только потом выполнять целевые действия;
• где возможно — дробить на порции;
• тяжёлые сценарии — переносить в фон.

Даже если полностью пакетный алгоритм сделать сложно, часто уже помогает разделение на этапы:

1. анализ;
2. подготовка;
3. запись только действительно изменившихся объектов.

 

7. "Небольшие" доработки в запросах, которые ломают производительность на больших объёмах

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

 

Почему это важно

Потому что деградация производительности не всегда связана с "грубой ошибкой" вроде запроса в цикле. Иногда проблема тоньше:

• сложное условие соединения;
• лишняя вложенность;
• неудачная структура запроса;
• расчётные выражения в неподходящем месте;
• обращение к данным через длинную цепочку ссылок;
• соединения, которые на маленьком объёме не чувствуются.

 

Практический вывод

Если запрос "вроде обычный", но работает непропорционально долго, я бы не ограничивался оценкой "на глаз". Я бы проверил:

• структуру запроса;
• соединения;
• логику условий;
• возможность упростить запрос;
• возможность разнести логику по этапам.

То есть плохая производительность запроса — это не всегда "слишком много строк". Иногда это просто неудачно выраженная мысль в тексте запроса.

 

8. Код становится медленнее не в одном месте, а от накопления связей

Отдельно хочу выделить эффект, который, по моему опыту, недооценивают.

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

Сценарий обычно выглядит так:

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

Каждая доработка по отдельности выглядит маленькой и допустимой. Но в сумме система проходит уже совсем другой маршрут выполнения.

И вот здесь самый неприятный момент: старое прикладное решение начинает "вязнуть" не потому, что кто-то однажды написал один очень плохой модуль. Чаще бывает наоборот: много маленьких доработок, каждая из которых по отдельности выглядела безобидно.

 

9. Как понять, что проблема в коде, а не только в инфраструктуре

Было бы неправильно сводить всю производительность 1С только к коду. Медленная работа действительно может быть связана с:

• сервером 1С;
• сервером СУБД;
• сетью;
• нехваткой ресурсов на клиентских ПК;
• антивирусом;
• настройками кластера;
• фоновыми заданиями;
• блокировками на уровне базы.

Но по моему опыту есть признаки, что корень проблемы именно в прикладном коде.

 

Признак 1. Тормозит не всё, а конкретный сценарий

• открытие определённой формы;
• проведение конкретного документа;
• работа одной обработки;
• заполнение табличной части;
• выполнение одной команды.

 

Признак 2. На малых данных проблема не воспроизводится

На копии с урезанной базой всё быстро, а на рабочей — нет.

 

Признак 3. Время выполнения растёт непропорционально количеству данных

Было 100 документов — работало 3 секунды.
Стало 1 000 — работает уже 4 минуты.

 

Признак 4. Есть зависимость от конкретных доработок

После добавления “небольшой проверки” форма стала открываться заметно дольше.

 

Признак 5. В коде видно повторяющиеся обращения и лишние объекты

Именно такие вещи я бы первым делом и искал.

 

10. Чем искать и как доказывать проблему

Одна из причин, почему подобные дефекты живут долго: разработчик часто чувствует, что код неудачный, но не всегда быстро может это доказать.

Лучше всего работают довольно приземлённые вещи:

• замеры времени выполнения отдельных этапов;
• разбиение алгоритма на участки;
• анализ количества обращений к БД;
• сравнение "до/после" на одинаковом наборе данных;
• проверка числа серверных вызовов в форме;
• анализ текста запросов;
• использование специализированных инструментов.

Сам подход здесь важнее всего: не гадать, а измерять.

 

11. Что я бы проверял первым, если "раньше работало быстрее"

Если приходит жалоба "стало медленно", я бы шёл примерно в таком порядке:

1. нет ли запросов в цикле;
2. нет ли массового ПолучитьОбъект();
3. нет ли записи объектов ради минимальных изменений;
4. не перегружена ли форма логикой открытия и изменения;
5. не читаются ли одинаковые данные по много раз;
6. не разбита ли пакетная задача на тысячи одиночных действий;
7. не усложнились ли запросы неочевидными соединениями и выражениями;
8. не добавились ли подписки, проверки и побочные эффекты в типовой сценарий;
9. нет ли внешней инфраструктурной причины: сеть, сервер, СУБД, блокировки.

То есть я бы шёл от самого вероятного и дешёвого в проверке — к более глубокому анализу.

 

12. Когда оптимизация не нужна

Это тоже важно проговорить.

Не любой "неидеальный" код надо немедленно переписывать.

Если решение:

• выполняется редко;
• работает на малом объёме;
• не влияет на пользовательский сценарий;
• не участвует в массовой обработке;
• не создаёт проблем сопровождения,

то излишняя оптимизация может оказаться дороже, чем сама проблема.

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

 

Вывод

Код в 1С редко начинает тормозить внезапно.

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

• работают "вполне нормально" на старте;
• быстро пишутся;
• легко проходят первичное тестирование;
• но плохо масштабируются.

На практике это почти всегда одни и те же вещи:

• запросы в цикле;
• лишние ПолучитьОбъект();
• запись объектов по одному;
• тяжёлая логика в формах;
• повторное чтение одних и тех же данных;
• отсутствие пакетного подхода;
• неочевидно тяжёлые конструкции в запросах.

Хорошая новость в том, что многие такие проблемы лечатся не "магией оптимизации", а довольно простыми вопросами:

• точно ли нужен объект;
• точно ли нужен отдельный запрос на каждом шаге;
• точно ли надо записывать всё подряд;
• точно ли форма должна делать эту работу;
• точно ли это нельзя обработать пакетно.

И если после чтения этой статьи вы хотя бы в нескольких местах своего кода поймаете себя на вопросе "а не делаю ли я здесь лишнее?" — значит, она была написана не зря.