Обновить

Про типичный паттерн, который помогает решать задачи по производительности в 1С.

Оптимизировали как-то мы обмен (как начало сказки звучит 😁). Вообще, началось не с обмена, а с “иногда 1С внезапно начинает тормозить”. Посмотрели журнал регистрации, выполнение регламентных и фоновых - увидели, что обмен идёт.

Обмен самописанный, под конкретную задачу. В одной базе живут продажи, в другой - номенклатура, цены, штрихкоды и т.д. (некая база с мастер-данными). Когда цены меняют, они должны сразу попасть в базу с продажами (там Розница стоит). Вот этот обмен и тормозил. Провели установку цен - подвисли. Обмен обычный, универсальный, с правилами (на конвертации данных 2).

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

Второй подозреваемый - количество выгружаемых данных. Здесь важно понимать паттерн - он часто помогает при оптимизации даже типовых 1Сных решений. Паттерн такой: разработчик почти всегда тестирует на ограниченных данных и в идеальной среде (если не было задачи именно оптимизированный алгоритм написать). Если он пишет обмен, то проверяет на 1-2-10 объектах. И на идеальной среде - в которой нет никого, кроме него. Если разрабатывает планирование, то для 2-3 заказов. И там, где он один. И т.д.

Вообще, это всё ежу понятно. Но когда дело доходит до проблем с производительностью, то почему-то паттерн этот часто забывается. Забывание выражается в том, что все исходят из предпосылки “там всё правильно сделано”. А это не всегда так. Оно сделано правильно, но для небольшого объёма данных и для среды, где нет пользователей и другой нагрузки.

Вот и в нашем случае, первые мысли были - переписать весь обмен. Вообще уйти от XML и правил, написать сервис. Потом немного одумались, вспомнили паттерн, и пошли проверять файл с сообщением обмена.

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

Дальше понятно. Просто убрали лишние данные из выгрузки (они и правда были лишними, ненужными - номенклатура обменивалась в другом контуре). Файл обмена уменьшился более чем вдвое, в правилах стало меньше запросов, и всё заколосилось.

https://t.me/another1C

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Путь к ИИ‑сингулярности

У нас было два репозитория неоттестированного вайб‑кода, семьдесят пять тяжеловесных SDD‑спецификаций, пять обмазанных смазкой харнессов, солонка, наполовину полная кастомных скиллов и забитых капслоком правил, с десяток дырявых MCP‑серверов, RAG‑база со свежевекторизованным Confluence, самодельная дощечка имаго‑кодинга и целая россыпь автономных агентов всех мастей, от безобидных автодополнялок до галлюцинирующих субагентов, ставящих пакеты со slopsquatting и втихаря сносящих боевые базы.

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

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

Нет ничего более беспомощного, безответственного и испорченного, чем IT‑команда, запустившая мультиагентный оркестр в режиме allow all.

Это критический (и слегка ехидный) обзор того, что произошло с разработкой последние пару лет.

Путь к ИИ‑сингулярности

Публикации