Стресс-тестирование обмена 1С и 1С-Битрикс

Обмен работает на небольшой базе, но ломается при реальных объёмах данных. Мы сталкивались с этим не раз: тест на 1 000 товаров проходит за минуту, а на 50 000 — таймаут PHP, переполнение памяти, deadlocks в базе. Типичные симптомы: сайт падает, 1С выдает ошибку импорта, требуется восстановление из бэкапа. Каждый сбой обмена в час пик может стоить до 200 000 рублей потерянной выручки. Стресс-тестирование обмена — это нагрузка данными, близкой к производственной, с фиксацией узких мест и предельных показателей до запуска в продакшн. Наш опыт: команда имеет 10+ лет опыта в разработке на Битрикс и провела более 50 стресс-тестов для каталогов от 10 000 до 500 000 SKU. При таком подходе выявление проблем на этапе тестирования экономит до 40% бюджета на срочные доработки. Получите консультацию по вашему обмену — мы оценим сценарий за один день.

Архитектура обмена и точки нагрузки

Стандартный обмен через CommerceML работает поэтапно:

1С → Экспорт XML (catalog.xml, offers.xml, import.xml) ↓ Битрикс → POST /bitrix/admin/1c_exchange.php ↓ Разбор XML (SimpleXML / XMLReader) ↓ Запись в b_iblock_element, b_iblock_element_property, b_catalog_price 

Узкие места при объёме 50 000+ SKU:

• Разбор XML — SimpleXML загружает весь файл в память. При файле 200 МБ на PHP с memory_limit = 256M — out of memory. Решение: XMLReader для потокового чтения.
• Запись в базу — стандартный CIBlockElement::Add() / CIBlockElement::Update() работает построчно. 50 000 элементов × 50 мс = 40 минут только на запись.
• Пересчёт цен — после каждого обновления цены пересчитываются накопительные скидки. При пакетной записи это нужно отложить на конец импорта.

Почему обмен ломается на больших объёмах?

Основные причины — архитектурные ограничения стандартных компонентов. SimpleXML создаёт дерево объектов в памяти, что для файла 200 МБ даёт >1 ГБ потребления. Плюс CIBlockElement::Add() выполняет множество отдельных SQL-запросов (проверка прав, события, кеширование). На 50 000 элементах число запросов переваливает за 500 000, что вызывает таймауты БД.

Как мы выявляем узкие места?

class CatalogXmlGenerator { public function generate(int $productCount, string $outputPath): void { $writer = new \XMLWriter(); $writer->openUri($outputPath); $writer->startDocument('1.0', 'UTF-8'); $writer->startElement('КоммерческаяИнформация'); for ($i = 1; $i <= $productCount; $i++) { $this->writeProduct($writer, $i); } $writer->endElement(); $writer->endDocument(); $writer->flush(); } private function writeProduct(\XMLWriter $w, int $i): void { $w->startElement('Товар'); $w->writeElement('Ид', "product-uuid-{$i}"); $w->writeElement('Наименование', "Тестовый товар #{$i}"); $w->writeElement('Артикул', "ART-{$i}"); // ... свойства, цены $w->endElement(); } } 

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

Генерируем XML-файл обмена с реалистичным объёмом: столько товаров, SKU и цен, сколько будет в продакшне плюс 30% запас.

Параметры замера

Типичные находки при стресс-тесте

Out of memory при разборе большого XML. Фикс: замена simplexml_load_file() на XMLReader с потоковой обработкой:

$reader = new \XMLReader(); $reader->open($filePath); while ($reader->read()) { if ($reader->nodeType === \XMLReader::ELEMENT && $reader->localName === 'Товар') { $node = new \SimpleXMLElement($reader->readOuterXml()); $this->processProduct($node); unset($node); // освобождаем память } } 

Рекомендация из документации PHP

Deadlocks при параллельном обмене. Если запущен cron-обмен и одновременно пришёл новый запрос из 1С — оба пишут в b_iblock_element_property. Фикс: lock-файл или запись состояния в b_option:

if (file_exists($lockFile)) { throw new \RuntimeException('Import already running'); } file_put_contents($lockFile, getmypid()); 

Медленная пересчёт скидок. После массовой записи цен вызывается CCatalogDiscount::CountDiscount() для каждого элемента. При 50 000 SKU — критичная нагрузка. Фикс: отключить автопересчёт через событие OnBeforeCatalogDiscountCounters на время импорта, запустить пересчёт одним вызовом после завершения.

Тест производительности отдельных операций

XMLReader в 5 раз эффективнее SimpleXML для больших файлов — это видно по времени парсинга 10 000 SKU.

Кейс: оптовый поставщик, 120 000 SKU

Проблема: обмен с 1С занимал 6 часов, завершался с ошибкой на 70% объёма из-за превышения max_execution_time.

Выполненные работы:

• Заменили SimpleXML на XMLReader — разбор XML с 40 мин до 8 мин
• Реализовали пакетный INSERT для свойств (500 записей за транзакцию) — запись с 3 часов до 35 мин
• Отложили пересчёт скидок на после импорта — сэкономили ещё 40 мин
• Разбили импорт на чанки по 5 000 элементов с checkpoint'ами — исключили потерю прогресса при ошибке

Итог: полный обмен 120 000 SKU за 47 минут, работает стабильно более полугода. Экономия времени — 80%.

Что входит в стресс-тестирование обмена

1. Генерация тестовых XML-файлов с реалистичным объёмом данных
2. Замер базовых показателей: время, память, SQL-запросы, CPU
3. Профилирование узких мест с рекомендациями по оптимизации
4. Исправление выявленных проблем: XMLReader, пакетная запись, lock-механизм
5. Повторный тест после оптимизации с подтверждением результата
6. Документация по предельным показателям и рекомендуемым настройкам сервера

Своевременное выявление проблем экономит от 100 000 рублей на экстренных исправлениях. Гарантируем, что после нашей доработки обмен выдержит заявленную нагрузку. Закажите стресс-тест и получите детальный протокол. Работаем по договору с фиксацией метрик в протоколе.

CommerceML