Нагрузочное тестирование обмена УТ↔БП: почему мок не ловит конфликты

15 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

Зачем тестировать обмен «вживую», а не моком

Mock-объект отвечает мгновенно и предсказуемо. Это удобно для юнит-теста, но даёт ложное успокоение, когда речь идёт об обмене двух баз 1С через планы обмена. В реальной интеграции живут три вещи, которые мок не воспроизводит:

• Очередь регистраций изменений. Каждое изменение, требующее обмена, регистрируется в плане обмена. На пиковой нагрузке очередь растёт быстрее, чем выгребается, и обмен начинает отставать.
• Конфликты одновременной записи. Менеджер в УТ изменил контрагента, бухгалтер в БП — тоже. Кто-то проиграет, кто-то выиграет, но мок этого даже не моделирует.
• Задержка распространения. Между «изменилось в УТ» и «появилось в БП» проходит время. На ненагруженной базе обычно секунды, под пиком может расти до минут — точные цифры зависят от интервала регламентного задания, размера пакета и объёма очереди. Бизнес-логика, рассчитанная на «сразу», начинает падать.

Что такое «связанные базы» в типовом 1С

Самый частый сценарий: УТ + БП, либо ERP + БП, либо два экземпляра одной конфигурации (например, две БП — головная и филиал). Внутри это организовано через планы обмена платформы. Каждый план описывает, между какими узлами идёт обмен, какие объекты передаются, и хранит очередь изменений на каждый узел.

// Простая диагностика: какие планы обмена есть в конфигурации
Для Каждого МДПланаОбмена Из Метаданные.ПланыОбмена Цикл
    Сообщить("План обмена: " + МДПланаОбмена.Имя
        + " (синоним: " + МДПланаОбмена.Синоним + ")");
КонецЦикла;

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

Что обычно идёт не так под нагрузкой

Как организовать тест двух баз

Подготовка стенда

Поднимите две копии продуктива на отдельном сервере (или паре серверов) — обе на железе, сопоставимом с боевым. Это критично: если тест идёт на двух одинаковых ноутбуках, а в продуктиве две машины по 64 ГБ — результаты не имеют смысла.

Сценарии

Минимум четыре класса сценариев, проходящих одновременно на обеих базах:

1. Создание новых сущностей на стороне А (контрагенты, документы реализации).
2. Изменение существующих сущностей на стороне Б (исправление реквизитов, перепроведение документов).
3. Параллельные изменения одного и того же объекта с обеих сторон (классический случай конфликта).
4. Массовая загрузка справочников с одной стороны, обычная работа с другой.

Что мерить

• Время одного полного цикла обмена (А → Б и обратно);
• Размер очереди регистраций изменений в начале и конце теста;
• Количество разрешившихся конфликтов и их сторона победителя;
• Длительность блокировок на приёмной базе во время обмена.

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

Чек-лист подготовки

1. Выделить две машины под стенд, сопоставимые с боевыми. Не ноутбуки.
2. Сделать копии обеих продуктивных баз. Обезличить чувствительные данные.
3. Зафиксировать настройки обмена (интервалы регламентных заданий, размер пакетов) такими же, как в проде.
4. Подготовить три-пять параллельных сценариев, в которых обе стороны активно изменяют пересекающиеся данные.
5. Зафиксировать стартовые показатели: размер очереди, время одного цикла обмена в спокойном режиме.
6. Запустить параллельные сценарии. Дать им поработать не менее одного полного цикла обмена туда-обратно.
7. Снять метрики после теста, сравнить со стартовыми. Зафиксировать конфликты, их количество и решения.
8. Для каждого узкого места — план: ускорить обмен (чаще регламент), сократить пакеты, изменить логику разрешения конфликтов, пересмотреть состав плана обмена, перейти на событийную регистрацию или разделить потоки по справочникам/документам.

Типичные ошибки

• Mock одной стороны. Mock мгновенно отвечает «ок» — реальная база отвечает через несколько секунд под нагрузкой. Большинство узких мест обмена — рост очереди регистраций, конфликты одновременной записи, задержка распространения — видны только на двух реальных базах под параллельной нагрузкой. Отдельные классы проблем (размер пакета, сериализация XDTO) можно ловить и на упрощённом стенде.
• Тест на пустых очередях. «У нас всё за 30 секунд!» — потому что в очереди ничего нет. На одном из стендов мы видели, как 30 секунд на пустой очереди превращались в десятки минут при очереди в сотни тысяч записей — конкретное соотношение зависит от размера пакета и регламента.
• Игнорирование конфликтов. «У нас обмен идёт, всё переезжает». А что переезжает — последняя версия или первая? На пересекающихся изменениях это критично, на большинстве реальных баз тестируется именно поведение разрешения конфликтов.
• Запуск всех сценариев в одну секунду. Реальная нагрузка размазана по часу: кто-то в 10:00, кто-то в 10:15. Тест с одновременным стартом создаёт неестественные пики и даёт ложную картину.
• Без замера базовой линии до теста. «Стало хуже» — это сравнение с чем? Без зафиксированного «как было до» вы не отличите реальную деградацию от случайного флуктуации.
• Тестируем только успешные сценарии. Обрыв обмена посреди передачи, недоступная база-приёмник, конфликт версий конфигурации — все эти ситуации тоже надо проиграть. Иначе на пиковом дне первая же сбойная ситуация остановит всё.