Задача: быстрее, но байт-в-байт так же
Ценообразование у заказчика - это две большие внешние обработки 1С (суммарно ~25 000 строк кода). По расписанию они считают цену каждой из десятков тысяч товарных позиций, записывают её в учётную систему и отправляют на витрины: в интернет-магазин, в розницу и в кабинеты трёх маркетплейсов.
К моменту обращения полный цикл пересчёта занимал 30-50 минут на контур. Регламент не успевал в отведённые окна, пересчёты “наезжали” друг на друга, изменения цен конкурентов доходили до витрин с опозданием.
Особенность задачи - цена ошибки. Обе обработки живые: пишут документы, проводят движения и публикуют цены в реальные кабинеты маркетплейсов. Любая ошибка оптимизации - это неверные цены на витрине у работающего ритейлера. Поэтому формулировка была жёсткой: ускорить, не изменив ни одной итоговой цены и не тронув контракт запуска.
Метод: замерный стенд и регрессия на каждую правку
Подход “поправил - вроде работает” здесь исключался. Мы построили замерный стенд на копии боевой базы и ввели правило: одна правка - один прогон - сравнение результата с эталоном побайтово.
- Эталон - полная таблица расчёта (~100 колонок на позицию: цены, маржа, статусы решений) плюс состав созданных документов. Вход фиксировался снапшотом внешних данных, чтобы расчёт был детерминированным.
- Правка принималась только при трёх условиях: результат идентичен эталону, этап не стал медленнее, в логе нет новых ошибок.
- Внешние эффекты на стенде глушились: отправка в API маркетплейсов, оповещения, рассылки - “выстрелить” тестовой ценой на реальную витрину недопустимо.
Всего - более 30 контролируемых прогонов, ~15 версий сборок, регрессия на 6 900-18 900 позициях за прогон. Дисциплина окупилась дважды: сверка поймала опечатку, ломавшую расчёт только в одном из четырёх контуров, и подтвердила, что застарелый известный баг ведёт себя одинаково до и после - то есть мы его не задели.
Диагноз: тормозила не логика, а доступ к данным
Узкие места искали не “на глаз”, а по системному монитору СУБД: какой запрос сколько времени и ресурсов ест фактически. Ни одно из найденных мест не потребовало менять формулы цен - всё лежало в том, как код обращается к базе:
- Срезы без отбора. Виртуальная таблица “срез последних” по регистру цен строилась по всей таблице, хотя дальше нужен был список конкретных товаров. Перенос отбора внутрь параметров среза - главный источник ускорений.
- Сравнения по строковому коду вместо ссылки. Условия вида
ТипЦен.Код = "000…"заставляют СУБД соединять справочник и фильтровать по тексту без индекса. Один такой запрос стоил 289 секунд - после замены кодов ссылками-параметрами стал 46 (×6,3). - Запросы в цикле. “Получить старую цену” вызывалось на каждую из десятков тысяч строк. Один пакетный запрос до цикла - и этап записи цен сжался с 810 до 43 секунд.
- Поиск O(N²). Линейный поиск строк по таблице ~19 тыс. × 19 тыс. итераций. Индекс таблицы значений - этап расчёта со 113 до 21 секунды.
- Транзакции по одной записи и тяжёлые выгрузки. Укрупнение порций записи, единые транзакции с фолбэком, потоковая работа с Excel-файлами по 83 МБ (493 → 263 с).
Отдельная история - запрос в блоке акций, работавший 39 минут. Монитор СУБД показал 2 353 секунды длительности и 124 секунды процессора: 95 % времени запрос не занимал процессор. По расписанию он стоял сразу за массовой записью цен, а срез делал по всему регистру цен без отбора. Отбор по нужным товарам сузил чтение: 39 минут превратились в 6 секунд при идентичном результате. Тот же анти-паттерн был исправлен ещё в пяти запросах блока акций.
Результат
Все контуры ускорены в 2-6 раз при бит-в-бит идентичном расчёте - полные цифры в таблице выше. Сверх плана:
- Оптимизированные запросы заметно устойчивее к чужой нагрузке: в час пик ключевой запрос выполняется за 256 секунд против прежних 1 179.
- Во второй волне запись цен вынесена вперёд выгрузок: цены попадают в базу через 3-4 минуты от старта вместо ~7, тяжёлый Excel ушёл в фоновое задание.
- Попутно найдены и исправлены два боевых бага, один из которых годами ронял шаг маркетплейс-обработки.
Внедрение - поэтапное, с боевыми прогонами: публикация цен на все три маркетплейса подтверждена, регистр цен сверён снапшотами “до/после” - из 24 205 позиций 0 потерь и 0 обнулений. Замерный стенд остался у заказчика как переиспользуемый инструмент для будущих доработок.
Как это было сделано: инженер + ИИ-агент
Честная деталь, которой мы гордимся: основную работу по диагностике и правкам в этом проекте выполнял ИИ-агент (Claude Code) под управлением и контролем нашего инженера. Агент читал код и статистику СУБД, находил узкие места, готовил правки и прогонял замеры; инженер ставил задачи, принимал каждое решение о выпуске и отвечал за результат.
Именно поэтому контур безопасности был таким жёстким: побайтовая регрессия после каждой правки - это не перестраховка, а то, что делает скорость ИИ безопасной для живого процесса. Связка дала темп, недостижимый для ручной работы: десятки проверенных правок в двух обработках на 25 000 строк - за считанные дни, с нулём изменений в итоговых ценах.
Почему это переносимо на вашу базу
В проекте нет ни одной “магической” правки: срезы с отбором, ссылки вместо строковых кодов, пакетные запросы вместо циклов, индексы таблиц значений, укрупнение транзакций. Это типовые болезни любой выросшей обработки - отличается только дисциплина проверки, которая позволяет чинить их в живом процессе без права на ошибку.
Самый показательный эпизод проекта - запрос на 39 минут, который почти всё это время не считал, а ждал, - разобран вместе с остальными приёмами проекта в статье 8 приёмов оптимизации запросов 1С. Там же SQL к статистике сервера, который находит ждущие запросы до первой правки.
Эта же обработка позже стала полигоном для отдельного эксперимента: четыре ИИ-агента получили одинаковое задание оптимизировать её автономно - один коммит конфигурации, лимит 90 минут, доступ к базе только на чтение, с безусловным откатом транзакции. Каждый нашёл своё узкое место, а один час проработал вслепую из-за ошибки доступа и всё равно сдал результат. Разбор с цифрами по каждому прогону - в статье “Можно ли доверить оптимизацию 1С нейросети”.
Если у вас регламентные обработки перестали влезать в свои окна - начните с экспресс-аудита: найдём фактические узкие места по монитору СУБД и оценим достижимое ускорение до начала работ. Подробнее об услуге - оптимизация производительности 1С.