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

Обмін з 50 000 товарами триває 4 години та блокує роботу всього сайту в робочий час. Це типовий симптом, коли каталог виріс у 10 разів, а налаштування залишилися колишніми. Кожна година простою коштує тисячі гривень. Ми щодня стикаємося з такими проектами: клієнти скаржаться на гальма, причина — у застарілому механізмі обміну. Оптимізація швидкості — це комплексний аудит та перепроектування як на стороні 1С, так і на стороні 1С-Бітрікс. Наш досвід — 10+ років з Бітрікс, понад 50 проектів з інтеграції. У цій статті розберемо ключові методи: пакетне завантаження, відкладену індексацію та кешування. Ви дізнаєтеся, як скоротити час обміну з кількох годин до 20–30 хвилин. Готові оцінити ваш проект? Зв'яжіться з нами для консультації — ми підготуємо пропозицію за один день. Вартість базової оптимізації — від 5 000 грн, а економія від зменшення простоїв може сягати 30 000 грн на місяць.

Як прискорити обмін 1С та Бітрікс без програмування?

Перш ніж братися за складні налаштування, переконайтеся, що використано базові методи. Ввімкніть ZIP-стиснення та розбийте вивантаження на пакети. Ці прості дії дають прискорення в 3–5 разів без жодного рядка коду. Далі — профілювання.

Профілювання обміну 1С

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

// В обробнику OnIBlockElementImport
$timings[] = [
    'step'    => 'element_import',
    'element' => $elementXmlId,
    'time'    => microtime(true) - $startTime,
];

Після обміну — проаналізувати: де проходить 80% часу. Варіанти:

• Розбір XML — файли занадто великі, не розбиті на частини
• Запис у БД — індекси, тригери, неоптимальні INSERT
• Перерахунок цін — якщо включено автоперерахунок цін за правилами
• Оновлення пошуку — переіндексація пошукового індексу при кожній зміні

Розбір XML як вузьке місце

Розбити вивантаження на пакети. У налаштуваннях 1С встановити «Кількість елементів у файлі» = 1000–2000. Кожен файл обробляється окремим HTTP-запитом. Бітрікс обробляє файл за 30–60 секунд замість зависання на 2+ години. Пакетна обробка в 10 разів швидша за поточкову.

Ввімкнути ZIP-стиснення. Файл з 2000 товарів без стиснення — 8–15 МБ, зі стисненням — 1–3 МБ. Для каналу між 1С та хостингом це суттєво, особливо при повільному з'єднанні. У налаштуваннях публікації 1С (протокол CommerceML): Использовать сжатие данных: Да, Порог сжатия: 1024 байт.

Оптимізація запису в базу даних

Стандартний імпорт Бітрікс викликає CIBlockElement::Add/Update для кожного елемента — це повний цикл з перевірками, обробниками подій та інвалідацією кешу. Для 50 000 елементів — 50 000 окремих транзакцій.

Вимкнути зайві події на час імпорту:

// Перед імпортом
define('BX_BUFFER_MESS', true); // не надсилати поштові сповіщення
$GLOBALS['STOP_STATISTICS'] = true; // не оновлювати статистику
define('NO_AGENT_STATISTIC', true);

Відкладена переіндексація. Пошук переіндексується після кожної зміни елемента. Для пакетного імпорту — вимкнути автоіндексацію та запустити переіндексацію окремим агентом після завершення обміну:

// Тимчасово вимкнути індексацію
\Bitrix\Main\Config\Option::set('search', 'indexer_auto_mode', 'N');

// Після обміну запустити переіндексацію
CSearch::ReIndexAll(true, CATALOG_IBLOCK_ID);

Батчова інвалідація кешу. Замість BXClearCache при кожному оновленні елемента — зібрати змінені елементи в масив та інвалідувати кеш батчем у кінці обміну.

Оптимізація запитів до БД при імпорті

При оновленні елемента Бітрікс робить SELECT для перевірки існування, потім UPDATE або INSERT. При пакетному імпорті можна попередньо завантажити всі XML_ID у пам'ять і не робити SELECT на кожен елемент:

// Одним запитом отримати всі існуючі елементи
$existing = [];
$res = CIBlockElement::GetList(
    [],
    ['IBLOCK_ID' => CATALOG_IBLOCK_ID],
    false,
    false,
    ['ID', 'XML_ID']
);
while ($el = $res->Fetch()) {
    $existing[$el['XML_ID']] = $el['ID'];
}

// Тепер при імпорті: isset($existing[$xmlId]) замість SELECT

Розділення обміну за типом даних

Повний обмін (каталог + ціни + залишки) в одному сеансі — надмірно. Розділити на незалежні потоки:

У 1С можна налаштувати кілька незалежних регламентних завдань для різних типів вивантаження.

Кешування на стороні Бітрікс

Перевірити налаштування кешу модуля каталогу:

Налаштування → Налаштування продуктів → Продуктивність:

• Кеш елементів каталогу: ввімкнути, TTL 3600 секунд
• Кеш властивостей: ввімкнути
• Кеш торгових пропозицій: ввімкнути для магазинів з варіантами

При обміні кеш інвалідується автоматично для змінених елементів. Якщо інвалідація займає багато часу — перевірити розмір кешу на диску (/bitrix/cache/iblock/), при необхідності збільшити memory_limit для обробки.

Кейс: скорочення часу обміну з 4 годин до 25 хвилин

Один із наших клієнтів — інтернет-магазин запчастин, 65 000 позицій. Обмін запускався раз на добу і займав 4+ години, блокуючи перерахунок цін на весь цей період. З нашої практики.

Знайдені проблеми:

1. Весь каталог в одному XML-файлі (240 МБ)
2. Переіндексація пошуку при кожному елементі
3. Перерахунок цін за 12 правилами на кожну зміну ціни
4. BXClearCache для всього інфоблоку на кожні 100 елементів

Після оптимізації:

• Розбивка на файли по 2000 елементів
• Відкладена переіндексація в окремому агенті
• Перерахунок цін — тільки після завершення імпорту, не в процесі
• Батчова інвалідація кешу в кінці сеансу

Результат: повний обмін — 25 хвилин. Обмін тільки залишками та цінами (щогодини) — 3–4 хвилини. Економія склала близько 30 000 гривень на місяць за рахунок зменшення простоїв сайту.

Що входить у роботу з оптимізації?

При замовленні послуги «під ключ» ми:

• Проводимо профілювання та аудит поточного обміну
• Розбиваємо вивантаження на пакети, налаштовуємо ZIP
• Вимкаємо зайві події, налаштовуємо відкладену індексацію
• Реалізуємо батчову інвалідацію кешу та попереднє завантаження XML_ID
• Розділяємо обмін за типом даних (каталог, ціни, залишки)
• Документуємо всі налаштування та передаємо інструкції

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

Оцінимо ваш обсяг і розкажемо точні терміни. Замовте аудит обміну — ми виявимо вузькі місця та запропонуємо план оптимізації. Наші сертифіковані фахівці з Бітрікс гарантують прискорення мінімум у 3 рази.

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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.