Что? Где? Когда? Играем по-взрослому: оптимизация обменов в 1С

12.09.25

Подробно разбираем архитектурные особенности обменов и показываем, как выжать максимум из доступных инструментов 1С. На реальных примерах демонстрируем приемы ускорения работы – от многопоточности и сериализации до оптимизации очередей и отложенного проведения документов. Материал будет полезен всем, кто работает с интеграциями и ищет практические способы повысить эффективность и устойчивость систем.

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

Меня зовут Сергей Локтев, моего соавтора – Сергей Непомнящий. В статье мы рассмотрим, как в рамках системы 1С можно и нужно оптимизировать каждый отдельный модуль.

Терминология интеграции: шестеренки системы

Начнем с терминологии. Что такое интеграция? Это сложный механизм, напоминающий часовой: каждая «шестеренка» играет свою роль, и малейшее замедление в одной из них приводит к снижению производительности всей системы.

Разберем основные элементы этого механизма:

Формирование очереди – процесс, при котором определяется, какие объекты из источника должны попасть в приемник.
Формирование пакетов – сериализация объектов 1С в промежуточный формат. Чаще всего объекты передаются не напрямую, а именно через такие форматы (XML, JSON и пр).
Канал обмена (транспорт) – способ передачи сформированного пакета в приемник.
Входящая очередь – организация приема пакетов. Здесь возможны разные варианты: пакеты обрабатываются сразу или сначала попадают в промежуточный буфер, а затем уже распаковываются.
Получение объектов – этап, на котором из пакета извлекаются данные, выполняется их запись, проведение и другие операции.

Фильтры и каналы обмена: что учитываем, а что упускаем

В интеграции можно выделить еще один важный элемент – фильтры. Их можно применять практически на каждом этапе: при формировании очереди, при создании пакета, в самом канале обмена и даже в приемнике.

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

Каналы обмена мы также оставим за рамками, так как сосредоточимся именно на возможностях 1С. Первые две «шестеренки» – это источник, вторые две «шестеренки» – это приемник.

Очереди в 1С: источники и их реализация

Теперь разберемся, какие объекты в 1С можно использовать для организации исходящей очереди:

План обмена. Этот механизм хорошо известен многим разработчикам, и подробно останавливаться на нем нет необходимости.
Сервисы интеграции. Начиная с версии платформы 8.3.17 появились встроенные сервисы интеграции. Первоначально они ориентированы на работу с 1С:Шина, но при желании их можно применять и для других задач – разумеется, с учетом определенных ограничений и особенностей.
Самописные очереди. В качестве альтернативы можно реализовать очередь самостоятельно – например, на базе справочников или регистров сведений. При этом документы для этих целей не подходят, так как движения нам не нужны, а регистры накопления без документов существовать не могут.

Зачем нужна очередь: риск потери данных

В целом очередь может и не использоваться, однако мы рассматриваем сценарии с ее применением. Почему это важно?

Если отказаться от очереди, то при выгрузке событий или данных всегда возникает риск их потери. Допустим, мы пытаемся передать информацию сразу, но в этот момент недоступен канал связи, файловый обменник или любой другой транспорт. В итоге либо блокируется выполняемая пользователем операция из-за отсутствия соединения, либо данные просто не передаются.

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

Замеры производительности формирования очередей

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

Для теста мы использовали набор из 2000 объектов: номенклатура, контрагент, организация и один документ поступления. Эти объекты поочередно добавлялись в разные типы очередей.

Планы обмена показали наилучший результат. Добавление заняло всего около 70 мс, то есть произошло практически мгновенно.
Справочники и регистры сведений. Скорость оказалась значительно ниже: порядка 10 секунд для тех же 2000 объектов. При этом работа шла достаточно равномерно.
Сервисы интеграции в тест не включались. Так как у них другая технология организации очереди, результаты было бы некорректно сравнивать.

Связь формирования очереди и создания пакетов

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

Формирование пакетов: влияние конвертации данных

Здесь планы обмена показывают максимально быструю работу, но важно помнить, что все зависит от технологии их использования. Чаще всего планы обмена применяются вместе с механизмами конвертации – будь то конвертация данных 2.1 или 3.0. При этом всегда есть дополнительный набор действий: распределение данных по пакетам, выполнение модулей и обработок и так далее.

В замерах, которые мы проводили, использовался упрощенный пример из Синтакс-Помощника: пакет формировался максимально быстро и сразу в формате JSON.

Мы сформировали JSON так, как это рекомендует Синтакс-Помощник. Но в реальной практике почти никто так не делает – чаще всего используется Конвертация данных 2.1.

Формирование пакета заняло более 80 секунд. Причем это только построение выгрузки, без записи объектов или сохранения файлов на диск.

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

Ускорение формирования пакетов: многопоточность

Что можно сделать, чтобы ускорить процесс? Формирование очереди у нас в любом случае идет достаточно быстро, и серьезно повлиять на него невозможно, кроме как сменой технологии. А вот формирование пакета – самый длительный этап, и здесь есть варианты. Один из них – использовать несколько потоков.

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

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

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

После внедрения многопоточности в других случаях получилась следующая картина:

Время формирования пакетов удалось сократить примерно на две трети – за исключением планов обмена.

Выбор технологии сериализации: JSON, XML, XDTO

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

Мы провели замеры для JSON, XML и XML через XDTO. Тестировали на одинаковых данных, исключив запросы, обработки и все лишнее – только чистое формирование объектов. Лидером оказался JSON, как минимум на этапе десериализации. Для теста использовались три типа данных: строка, дата и число.

Сначала мы проверили только сериализацию – само формирование пакета. Думали, что XML окажется быстрее, ведь там есть фабрика и ряд встроенных платформенных механизмов. Но при сравнении оказалось, что при десериализации через XDTO результат лучше, чем у обычного XML. Однако по сравнению с обоими вариантами JSON заметно быстрее.

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

Оптимизация через отказ от полей поиска

Еще один способ ускорить формирование пакета – это отказаться от полей поиска. Для Конвертации данных 2.1 мы сделали следующее: оставили поиск только по идентификатору и убрали ключи поиска у всех остальных полей.

По сути, мы избавили механизм конвертации от циклических запросов для каждого объекта. В результате замеров мы получили выигрыш примерно 25%, что составило около 20 секунд.

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

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

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

Очереди на стороне приемника: типы и организация

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

Для начала разберемся с типами входящих очередей:

Без входящей очереди – обработка происходит сразу в оперативной памяти. Пример такого подхода – план обмена. В некоторых случаях можно настроить справочники или регистры сведений так, чтобы туда записывались только ошибки. Все остальное выполняется в оперативной памяти.
Очередь в канале – это отдельная очередь, которая технически находится вне приемника и служит дополнительным буфером.
Очередь в приемнике – используется, когда канал слабый или когда нужно выгрузить из промежуточной очереди большой объем данных и затем постепенно их обработать. Такой подход также позволяет применять технологии вроде многопоточности для ускорения обработки.

Разделение нагрузки и приоритеты в очередях

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

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

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

Организация очереди в сервисах интеграции

Стоит упомянуть, что сервис интеграции, который на изображении обозначен со «звездочкой», устроен нетипично. Там есть отдельные сервисы для отправки и получения. Именно на этапе отправки мы можем управлять очередью: данные записываются в сервис, а затем вычитываются.

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

Вопрос в том, как можно обойти это ограничение, чтобы объекты при получении загружались достаточно быстро? Где еще можно найти точки для ускорения в рамках рассматриваемых процессов?

Ускорение поиска объектов в приемнике

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

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

Организация и замеры регистров сведений для сопоставления

Как можно организовать такой регистр сведений? В БСП уже существует свой регистр для обменов (на изображении). Он имеет индексацию, но ее назначение часто остается непонятным.

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

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

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

Мы провели замеры для трех вариантов: поиск по GUID, поиск по полям и использование регистра сведений. Первый замер – самый быстрый, так как нет поиска, данные определяются по GUID. Второй и третий замеры – это поиск по GUID и дополнительным полям. Причем поля могут быть как индексированными, так и не индексированными. Это тоже нужно учитывать. По четвертому и пятому замеру на картинке ускорения никакого нет, а есть даже замедление. Но важно понимать, что это происходит только один раз, когда мы делаем сопоставление. Все остальные разы мы идем по последнему седьмому замеру (GUID + регистр соответствия). То есть первоначальное сопоставление идет долго, так как происходит запись в регистр сведений. Дальнейшее обращение к существующим сопоставлениям происходит даже быстрее поиска по полям с индексами.

Влияние объема данных и индексации на производительность

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

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

Оптимизация обработки документов: варианты проведения

Еще один способ ускорить процесс – обратить внимание на то, как мы записываем данные.

Для справочников, регистров сведений и других объектов (кроме документов) возможности оптимизации ограничены платформой. С документами ситуация иная, потому что они чаще всего сопровождаются проводками – без движений документ теряет смысл. Документ без движений практически не используется.

Что можно сделать с документами? Есть несколько вариантов:

Сразу проводить. При десериализации документ записывается и сразу формируются движения.
Записать, а движение приходит каким-то отдельным пакетом. Это похоже на механизм РИБ: движения формируются автоматически, что подходит для идентичных конфигураций.
Отложенное проведение. При загрузке пакета документ записывается, а движения формируются позже отдельной регламентной обработкой,
Частичное проведение. В момент загрузки можно провести документ и сформировать только те движения, которые нужны прямо сейчас, а остальные, например для закрытия месяца, выполнять отдельным регламентным заданием.

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

Замеры времени обработки документов

Замеры показывают, что если мы просто записываем документ, это занимает примерно 20 секунд.

Важно понимать, что здесь речь идет не об автоматической интеграции. Автоматическая интеграция – это когда событие в одной системе автоматически появляется в другой без участия пользователя. Если же пользователю нужно потом провести документ вручную, мы фактически перекладываем на него эту работу. Либо речь идет о небольших объемах данных, либо о дополнительных действиях пользователя.

Разберем наши варианты:

Запись документов без проводок – только фиксация объекта, движения не формируются.
Запись с проведением – стандартное проведение документа с формированием всех необходимых движений.
Запись + отложенное формирование движений – документ записывается, но движения формируются отдельно. Движения записываются непосредственно в регистр накопления, без команды документа ОбработкаПроведения.
Частичное + отложенное проведение – часть движений формируется и проводится сразу, остальные движения формируются и записываются в регистр накопления позже, но при этом выполняются команды документа ОбработкаПроведения.
Частичное проведение + отложенное в регистр накопления – сразу формируются только необходимые движения, остальные движения записываются непосредственно в регистр накопления, без команды документа ОбработкаПроведения.

Что мы пытаемся здесь выиграть? Во-первых, при частичном проведении мы выделяем только ту часть информации, которая нужна в данный момент.

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

Примеры оптимизации в реальных кейсах

Замеры проводились на такой виртуальной машине. Хотелось бы показать несколько примеров, как все это работает на реальных кейсах.

Возьмем типовой объект и типовой обмен на КД 3 и Enterprise Data. Что здесь можно улучшить? По сути, система работает уже достаточно эффективно.

Мы отказываемся от поиска по ключевым полям и применяем отложенное проведение документов. Это позволяет сократить время формирования пакетов как на источнике, так и на приемнике, а также уменьшить длительность транзакций.

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

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

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

Конечно, когда мы говорим про то, что отказываемся от формирования очереди для каждого узла, где-то внутри на схеме должно появиться, что у нас появился либо брокер сообщения, либо шина данных, которая уже в очереди это сделает для каждого приемника.

В приемнике мы загружаем пакеты справочника, в четыре потока их обрабатываем, и у нас получаются объекты. Видно частично отложенное проведение и поиск по GUID.