Как ускорить и облегчить выгрузку из 1С

Выгрузка из 1С «тормозит» не потому, что каталог большой, а потому, что весь объём гоняется целиком в каждом сеансе. Разберём, где именно теряется время, и как настроить детальный, пошаговый обмен, чтобы сайт обновлялся за минуты, а не за часы.

Где на самом деле теряется время

Прежде чем что-то оптимизировать, нужно понять, какой этап обмена долгий. Стандартный протокол CommerceML между «1С:Управление торговлей» и модулем catalog Битрикса делится на две фазы: выгрузка (1С формирует XML и отдаёт его сайту) и импорт (сайт разбирает XML и пишет данные в БД). Медленной может быть любая.

• Формирование XML в 1С — упирается в производительность самой базы 1С и в размер номенклатуры. Если каждый раз выгружается весь каталог, а не изменения, время линейно растёт вместе с числом позиций.
• Передача файла — большой import.xml целиком уходит по HTTP одним POST-запросом. На медленном канале или при жёстких лимитах веб-сервера это и есть узкое место.
• Импорт на сайте — самая частая проблема. Битрикс на каждый товар делает выборки на соответствие, обновляет инфоблок, торговые предложения, цены, остатки и перестраивает индексы.

Детальный обмен вместо полной выгрузки

Главный рычаг — перейти с полной выгрузки на обмен только изменениями. В типовых конфигурациях 1С за это отвечает флаг «Выгружать только изменения» в настройках узла обмена с сайтом. Тогда 1С хранит регистрацию изменений и в очередном сеансе формирует XML лишь по тем товарам, ценам и остаткам, которые реально поменялись.

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

1. Первый обмен всё равно будет полным — 1С обязана один раз передать весь каталог, чтобы установить соответствие идентификаторов XML_ID.
2. Остатки и цены при частых изменениях выгодно выносить в отдельный, более частый сеанс — их файлы легче, а актуальность важнее.
3. Если соответствие «слетело» (например, пересоздали инфоблок), нужно принудительно выполнить полную выгрузку один раз, иначе часть товаров задвоится.

Разбиение файла и пошаговый импорт

Даже корректный XML нельзя обрабатывать одним запросом — веб-сервер убьёт долгий процесс по таймауту. Протокол CommerceML для этого предусматривает два параметра, которые задаются на стороне 1С в настройках обмена.

На стороне сайта размер порции регулируют константы в /bitrix/php_interface/init.php: например IBLOCK_1C_INTERVAL — время (сек) на один шаг импорта, после которого Битрикс сам сохраняет прогресс и запрашивает продолжение. Слишком крупная порция ловит таймаут, слишком мелкая — раздувает число запросов. Оптимум обычно 20–40 секунд на шаг.

Лимиты PHP и веб-сервера

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

• memory_limit — минимум 256M, для тяжёлых каталогов 512M и выше; нехватка памяти даёт «белый экран» на импорте.
• max_execution_time — должно быть не меньше интервала шага; при пошаговом обмене каждый запрос всё равно должен успеть завершиться.
• post_max_size и upload_max_filesize — если файл разбивается, они должны вмещать самую крупную часть с запасом.
• Тайм-ауты веб-сервера — proxy_read_timeout в Nginx и request_terminate_timeout в PHP-FPM; при коротких значениях длинный шаг обрывается с ошибкой 502/504.

Изображения, свойства и торговые предложения

Отдельно тормозят те данные, которые формально не про товар, но передаются вместе с ним. Их стоит настроить прицельно.

• Картинки. Обмен изображениями — самый «тяжёлый» трафик. Если фото не менялись, отключите их повторную выгрузку и оставьте только для новых позиций. Битрикс сравнивает файлы по хэшу, но само вложение всё равно раздувает XML.
• Свойства и характеристики. Выгружайте на сайт только те реквизиты, которые реально используются в карточке и фильтре. Лишние свойства — это лишние записи в b_iblock_element_property и медленный импорт.
• Торговые предложения. Большая вложенность вариаций (цвет × размер × упаковка) кратно увеличивает число элементов дочернего инфоблока. Пересмотрите, все ли характеристики должны быть отдельными SKU.

Ещё один приём — развести каталог и остатки/цены по разным сеансам: тяжёлый обмен номенклатурой раз в сутки ночью, а лёгкий обмен ценами и остатками — каждые 10–15 минут.

Расписание и мониторинг

Ускорение бесполезно, если обмен запускается в пиковые часы и конкурирует с покупателями за ресурсы. Настройте автоматический обмен так, чтобы тяжёлые сеансы уходили на ночь. В типовой 1С это регламентное задание обмена с сайтом, на стороне Битрикса — агент или внешний вызов 1c_exchange.php по расписанию.

• Полная синхронизация каталога — ночью, в период низкой нагрузки.
• Цены и остатки — короткими частыми сеансами в течение дня.
• Заказы — отдельным потоком, чтобы длинная выгрузка каталога не задерживала передачу новых заказов в 1С.

Обязательно ведите наблюдение: время каждого сеанса, размер файлов, число ошибок в exchange.log. Резкий рост длительности — сигнал, что где-то снова включилась полная выгрузка или распухли торговые предложения. Раннее выявление дешевле, чем разбор, почему сайт «не обновляет цены» в разгар распродажи.

Итог

Быстрый обмен — это не один волшебный флаг, а связка настроек: детальная выгрузка только изменений, разбиение файла и пошаговый импорт, адекватные лимиты PHP и веб-сервера, разумный набор свойств и изображений и расписание, разводящее тяжёлые и лёгкие сеансы. Начинать всегда стоит с диагностики логов, а не с тюнинга наугад.

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