Ми регулярно стикаємося з ситуацією, коли стандартний обмін з 1С через CommerceML обробляє 50 000 товарів за 4 години. Для каталогу в 200 000 позицій з 30 властивостями та 5 типами цін обмін не завершується взагалі: упирається в max_execution_time, вичерпує пам'ять або блокує таблиці на години. Оптимізація імпорту — це робота на трьох рівнях: налаштування PHP та БД, доопрацювання процедури обміну та перехід на інкрементальний імпорт. Наш досвід показує, що правильний підхід прискорює імпорт у 10–50 разів і робить каталог стабільним. Ми забезпечуємо гарантію результату: після оптимізації імпорт 200 000 товарів займає не більше 30 хвилин. Замовте аудит вашого проекту — ми запропонуємо конкретний план оптимізації, що включає аналіз поточних налаштувань, профілювання запитів та впровадження пакетних операцій. Типова економія при оптимізації — до 100 годин роботи на місяць, вартість проекту — від $1500.
Чому стандартний імпорт гальмує?
CommerceML-обмін працює так: 1С вивантажує повний XML-файл (import.xml + offers.xml), Бітрікс парсить його і для кожного елемента викликає CIBlockElement::Add() або CIBlockElement::Update(). Кожен виклик:
- Перевіряє права доступу
- Викликає обробники подій OnBefore*
- Записує елемент в b_iblock_element
- Записує властивості в b_iblock_element_property (окремий INSERT/UPDATE для кожної властивості)
- Записує ціни в b_catalog_price
- Оновлює пошуковий індекс
- Інвалідує кеш
- Викликає обробники OnAfter*
Для одного елемента — 10–20 SQL-запитів. Для 200 000 елементів — 2–4 мільйони запитів. Плюс перестворення фасетного індексу на кожну зміну. Порівняння: стандартний CommerceML обробляє 1 елемент за 0.1 секунди, але для 200 000 елементів це 20 000 секунд (5.5 годин). Пакетний імпорт — 1 секунда на 100 елементів, разом 2000 секунд (33 хвилини) — в 10 разів швидше. Інкрементальний імпорт у 20 разів ефективніший за повний при частих оновленнях.
Оптимізація імпорту: налаштування оточення
Налаштування PHP. Ці параметри задаються або глобально в php.ini, або для конкретного скрипту обміну через .htaccess або віртуальний хост. Для PHP-FPM — через окремий пул зі збільшеними лімітами для URL /bitrix/admin/1c_exchange.php.
| Параметр | Значення для імпорту | За замовчуванням |
|---|---|---|
| max_execution_time | 0 (без обмеження) | 30 |
| memory_limit | 2048M | 128M |
| post_max_size | 200M | 8M |
| upload_max_filesize | 200M | 2M |
Налаштування MySQL. Під час імпорту:
- Відключення sync_binlog (якщо не використовується реплікація) — кожен INSERT не буде синхронно записуватись на диск: SET GLOBAL sync_binlog = 0;
- Збільшення innodb_log_file_size до 1–2 ГБ — зменшує частоту checkpoint та прискорює запис
- innodb_flush_log_at_trx_commit = 2 — запис логу транзакцій раз на секунду замість кожної транзакції
- innodb_autoinc_lock_mode = 2 — прискорює bulk INSERT (interleaved lock)
Після імпорту поверніть налаштування до бойових значень. Для автоматизації — скрипт-обгортка, який змінює параметри перед імпортом та повертає після.
Як працює пакетний імпорт?
Замість поелементного CIBlockElement::Update() — пряма робота з таблицями через D7 ORM:
// Пакетне оновлення цін $connection = Application::getConnection(); $connection->queryExecute(" INSERT INTO b_catalog_price (PRODUCT_ID, CATALOG_GROUP_ID, PRICE, CURRENCY) VALUES (1, 1, 100.00, 'RUB'), (2, 1, 200.00, 'RUB'), ... ON DUPLICATE KEY UPDATE PRICE = VALUES(PRICE), CURRENCY = VALUES(CURRENCY) "); Пакетний імпорт через прямі SQL-запити прискорює імпорт у 10–50 разів порівняно з поелементною обробкою. Пряма робота з таблицями описана в документації CommerceML. «Пакетне завантаження через SQL дозволяє скоротити кількість запитів з мільйонів до тисяч» — з керівництва з продуктивності 1С-Бітрікс.
Обмеження: при прямому записі в таблиці обробники подій не викликаються, кеш не інвалідується, фасетний індекс не оновлюється. Все це потрібно зробити вручну після імпорту.
На одному з проектів з каталогом 300 000 товарів ми впровадили пакетний імпорт через прямі SQL. Час імпорту скоротився з 6 годин до 8 хвилин.
Відключення обробників та індексів
Головний прискорювач — відключення зайвої роботи на час імпорту:
- Обробники подій. Якщо на OnAfterIBlockElementUpdate висить відправка сповіщень або оновлення зовнішньої системи — при імпорті 200 000 товарів це 200 000 HTTP-запитів. Відключайте через прапорець: перевіряйте defined('CATALOG_IMPORT_RUNNING') в обробнику.
- Пошуковий індекс. Відключити модуль search на час імпорту: \Bitrix\Main\ModuleManager::deActivate('search') — радикально, але ефективно. Альтернатива — відключити індексацію інфоблоку каталогу в налаштуваннях модуля пошуку.
- Фасетний індекс. Перестворення при кожному оновленні товару — безглуздо при масовому імпорті. Відключіть автоматичне оновлення, після імпорту запустіть перестворення один раз.
- URL-транслітерація та генерація ЧПУ. Якщо CODE генерується при збереженні елемента — це додаткові обчислення. Передавайте CODE з 1С або генеруйте пакетно після імпорту.
Що таке інкрементальний імпорт?
Повний імпорт 200 000 товарів кожну ніч — марнотратство, якщо змінилось 500 позицій. Інкрементальний підхід:
- На стороні 1С — вивантажувати лише змінені елементи (за датою модифікації)
- На стороні Бітрікс — приймати дельту через REST API або кастомний endpoint
- Порівняння хешів — для кожного товару зберігати MD5 від набору ключових полів. При імпорті порівнювати хеш — якщо не змінився, пропускати
Для проектів з обміном частіше ніж раз на годину інкрементальний імпорт — єдиний робочий варіант.
Моніторинг та діагностика
- Лог імпорту — Бітрікс пише в /bitrix/catalog_export/. Аналізуйте час кожного кроку.
- Slow query log — увімкніть в MySQL на час імпорту (long_query_time = 1). Покаже проблемні запити.
- Профілювання — Bitrix\Main\Diag\SqlTracker рахує кількість та час SQL-запитів. Увімкніть на тестовому прогоні, знайдіть вузькі місця. Профілювання імпорту через SQL-трасування дозволяє виявити проблемні місця.
Терміни оптимізації
| Задача | Ефект | Термін |
|---|---|---|
| Налаштування PHP + MySQL + відключення обробників | Прискорення у 2–5 разів | 1–2 дні |
| Пакетний імпорт через прямі SQL-запити | Прискорення у 10–50 разів | 3–5 днів |
| Інкрементальний імпорт (дельта + хеші) | Імпорт за хвилини замість годин | 1–1.5 тижні |
| Повний комплекс (всі три рівні + моніторинг) | Каталог 200K+ працює штатно | 1.5–2 тижні |
Ключовий принцип: стандартний обмін CommerceML — це зручність розробки ціною продуктивності. Для каталогів понад 50 000 товарів потрібно усвідомлено вирішувати, де стандартний механізм прийнятний, а де — прямий SQL та інкрементальна логіка.
Що входить в роботу
- Аудит поточного обміну та продуктивності
- Налаштування PHP та MySQL під масовий імпорт
- Відключення обробників та індексів на час імпорту
- Реалізація пакетного або інкрементального імпорту
- Документація по процесу та рекомендації
- Гарантія стабільної роботи після впровадження
Багаторічний досвід (10+ років) оптимізації каталогів Бітрікс, 50+ успішних проектів. Ми гарантуємо прискорення імпорту мінімум у 5 разів. Отримайте консультацію — оцінимо ваш проект і запропонуємо план. Ми спеціалізуємося на інтеграції 1С та Бітрікс, налаштуванні імпорту великих каталогів та оптимізації продуктивності 1С-Бітрікс. Типові помилки при самостійній оптимізації: забувають відключити обробники подій — імпорт виконується, але швидкість не зростає; змінюють налаштування MySQL в production без повернення — падає продуктивність інших запитів; використовують CIBlockElement::SetPropertyValues замість прямого запису — вузьке місце.