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

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

Почему выгрузка тормозит

Обмен между 1С и Битриксом идёт по протоколу CommerceML 2 через точку входа /bitrix/admin/1c_exchange.php. 1С по HTTP выгружает XML-файлы (import.xml, offers.xml), а Битрикс разбирает их пошагово, создавая и обновляя элементы инфоблока каталога и торговых предложений.

Медленным процесс делают, как правило, несколько вещей одновременно:

• полная выгрузка вместо изменений — 1С каждый раз отдаёт весь каталог целиком;
• слишком крупные порции — Битрикс пытается обработать тысячи товаров за один шаг и упирается в max_execution_time;
• тяжёлые побочные операции — переиндексация поиска, пересчёт умного фильтра, генерация изображений на каждом шаге;
• картинки — выгрузка и ресайз изображений часто занимает больше времени, чем сами данные.

Дельта-обмен: выгружать только изменения

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

Практическая схема, которая хорошо работает на живых магазинах:

• полный обмен — по расписанию раз в сутки ночью, когда нагрузка минимальна;
• частые короткие обмены остатками и ценами — каждые 10–30 минут, только дельта.

Для оперативных данных выгрузку остатков и цен стоит отделить от выгрузки самих товаров — она на порядок легче, потому что не трогает свойства и картинки. Битрикс распознаёт такой режим по содержимому offers.xml и обновляет только поля количества и цены.

Порции и размер пакета

Обмен устроен пошагово: 1С шлёт запрос ?mode=import&step=…, Битрикс обрабатывает очередную порцию элементов и возвращает progress, после чего 1С шлёт следующий шаг. Размер порции — ключевой параметр баланса между скоростью и стабильностью.

Настраивается он с двух сторон:

Общее правило: меньше порция — стабильнее, но больше накладных расходов на HTTP. Если обмен падает по таймауту, порцию уменьшают (например, до 20–50 элементов на шаг); если сервер мощный и запас по времени большой, порцию наращивают, чтобы сократить число обращений. Разумная отправная точка для среднего каталога — 50 элементов на шаг с ограничением файла порядка 1024 КБ.

Серверные лимиты PHP

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

• max_execution_time — время на один шаг; при мелких порциях 30–60 секунд обычно достаточно;
• memory_limit — память на разбор XML и обновление свойств; для каталога с торговыми предложениями закладывают 256M и выше;
• max_input_time и лимиты загрузки — влияют на приём файлов от 1С.

В Битриксе есть собственный тормоз безопасности — константа BX_CATALOG_IMPORT_TIME_LIMIT (в /bitrix/php_interface/dbconn.php или в настройках), которая ограничивает длительность одного шага импорта, чтобы скрипт корректно завершался и отдавал управление 1С. Её значение согласуют с max_execution_time: шаг Битрикса должен завершаться раньше, чем PHP оборвёт процесс.

Что отключить на время импорта

Много времени съедают операции, которые Битрикс выполняет «попутно» на каждом сохранении элемента. На время массовой выгрузки их разумно отложить:

1. Переиндексацию поиска. Обновление поискового индекса на каждый товар сильно замедляет обмен — индекс лучше пересобрать один раз после завершения импорта.
2. Пересчёт свойств умного фильтра. В настройках инфоблока каталога включите отложенный пересчёт фасетного индекса, а не после каждого элемента.
3. Внешние обработчики событий. Ваши OnAfterIBlockElementUpdate и подобные хендлеры при импорте отрабатывают тысячи раз; проверьте, что они не делают тяжёлых запросов, и при необходимости отключайте их по флагу режима обмена.

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

Контроль, логи и диагностика

Чтобы ускорять обмен осознанно, нужно видеть, где именно уходит время. Битрикс ведёт журнал сессии обмена — включите его в настройках торгового каталога, и подробности лягут в файл вида /bitrix/tmp/__1c_exchange.log (либо в каталог, указанный в настройках модуля).

На что смотреть при диагностике:

• на каком шаге и типе данных (товары, предложения, остатки) обмен замедляется или падает;
• сколько элементов реально обновилось — если при дельте обновляется весь каталог, значит изменения не отслеживаются и 1С шлёт всё;
• ошибки таймаута и памяти в логах веб-сервера и PHP.

Итог

Ускорение выгрузки из 1С — это не одна «волшебная галочка», а сумма настроек: перевод на дельта-обмен, разделение потоков (товары отдельно, цены и остатки отдельно), подбор размера порций, адекватные лимиты PHP и отключение побочных операций вроде переиндексации на время импорта. В связке это превращает многочасовой обмен в короткие предсказуемые сессии, которые не роняют сайт в часы нагрузки.

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