Оптимізація імпорту великих обсягів даних 1С-Бітрікс

Ми регулярно стикаємося з ситуацією, коли стандартний обмін з 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(). Кожен виклик:

1. Перевіряє права доступу
2. Викликає обробники подій OnBefore*
3. Записує елемент в b_iblock_element
4. Записує властивості в b_iblock_element_property (окремий INSERT/UPDATE для кожної властивості)
5. Записує ціни в b_catalog_price
6. Оновлює пошуковий індекс
7. Інвалідує кеш
8. Викликає обробники 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.

Налаштування 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. На стороні 1С — вивантажувати лише змінені елементи (за датою модифікації)
2. На стороні Бітрікс — приймати дельту через REST API або кастомний endpoint
3. Порівняння хешів — для кожного товару зберігати MD5 від набору ключових полів. При імпорті порівнювати хеш — якщо не змінився, пропускати

Для проектів з обміном частіше ніж раз на годину інкрементальний імпорт — єдиний робочий варіант.

Моніторинг та діагностика

• Лог імпорту — Бітрікс пише в /bitrix/catalog_export/. Аналізуйте час кожного кроку.
• Slow query log — увімкніть в MySQL на час імпорту (long_query_time = 1). Покаже проблемні запити.
• Профілювання — Bitrix\Main\Diag\SqlTracker рахує кількість та час SQL-запитів. Увімкніть на тестовому прогоні, знайдіть вузькі місця. Профілювання імпорту через SQL-трасування дозволяє виявити проблемні місця.

Терміни оптимізації

Ключовий принцип: стандартний обмін CommerceML — це зручність розробки ціною продуктивності. Для каталогів понад 50 000 товарів потрібно усвідомлено вирішувати, де стандартний механізм прийнятний, а де — прямий SQL та інкрементальна логіка.

Що входить в роботу

• Аудит поточного обміну та продуктивності
• Налаштування PHP та MySQL під масовий імпорт
• Відключення обробників та індексів на час імпорту
• Реалізація пакетного або інкрементального імпорту
• Документація по процесу та рекомендації
• Гарантія стабільної роботи після впровадження

Багаторічний досвід (10+ років) оптимізації каталогів Бітрікс, 50+ успішних проектів. Ми гарантуємо прискорення імпорту мінімум у 5 разів. Отримайте консультацію — оцінимо ваш проект і запропонуємо план. Ми спеціалізуємося на інтеграції 1С та Бітрікс, налаштуванні імпорту великих каталогів та оптимізації продуктивності 1С-Бітрікс. Типові помилки при самостійній оптимізації: забувають відключити обробники подій — імпорт виконується, але швидкість не зростає; змінюють налаштування MySQL в production без повернення — падає продуктивність інших запитів; використовують CIBlockElement::SetPropertyValues замість прямого запису — вузьке місце.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

Що входить у роботу?

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.