Прискорення Highload-блоків: аудит, індекси, кеш, партиціонування

Прискорення роботи Highload-блоків: підходи та інструменти

Уявіть: highload-блок з історією замовлень на 5 млн рядків — запит вибірки за датою фільтрації виконується 40 секунд. Після оптимізації — 8 мілісекунд. Таке можливе при правильному індексуванні, кешуванні та партиціонуванні. Highload-блоки (модуль highloadblock) — механізм Бітрікс для зберігання довільних даних в окремих таблицях. Популярні застосування: журнали подій, каталоги товарів з нестандартною структурою, профілі користувачів, накопичувальні дані (історія замовлень, аналітика, черги). Доки рядків менше 50–100 тисяч — все працює нормально. При 1–10 мільйонах рядків починаються проблеми: ORM Бітрікс генерує неоптимальні запити, індекси не покривають реальні вибірки, JOINи гальмують. Ми стикалися з проектами, де час вибірки сягав 40 секунд — після оптимізації падав до 8 мілісекунд. Економія часу на кожному запиті — до 99.9%.

Чому highload-блоки гальмують на великих даних?

Основні антипатерни при роботі з Highload:

• Відсутність потрібних індексів. Highload-блок створює таблицю з первинним ключем ID та автоінкрементом. Користувацькі поля типу UF_* не індексуються автоматично. Вибірка getList(['filter' => ['UF_PRODUCT_ID' => 123]]) при мільйоні рядків — це table scan.
• SELECT *-подібні запити. ORM Бітрікс за замовчуванням вибирає всі поля. Якщо у запису 30 UF-полів, включаючи TEXT та FILE, це дорогий запит навіть при малому result set.
• Необмежені вибірки без пагінації. DataManager::getList() без limit поверне всі записи в пам’ять PHP.
• Пов’язані таблиці через Reference. Якщо Highload пов’язаний з іншим Highload або інфоблоком через Reference-поля — ORM будує JOIN, який без правильних індексів вбиває продуктивність.
• Часті UPDATE по полях без індексу. Типово для статусних полів, лічильників.

Як діагностувати вузькі місця?

Вмикаємо лог повільних запитів MySQL:

[mysqld]
slow_query_log        = 1
slow_query_log_file   = /var/log/mysql/slow.log
long_query_time       = 1
log_queries_not_using_indexes = 1

Як правильно індексувати highload-таблиці?

Додаємо індекси через прямий SQL — в агенті при встановленні або в migration-скрипті:

$connection = \Bitrix\Main\Application::getConnection();
$tableName = 'b_hl_product_catalog'; // Приклад
$connection->queryExecute(
    "CREATE INDEX IF NOT EXISTS idx_product_id ON {$tableName} (UF_PRODUCT_ID)"
);
$connection->queryExecute(
    "CREATE INDEX IF NOT EXISTS idx_status_date ON {$tableName} (UF_STATUS, UF_DATE_CREATE)"
);

Що робити, якщо ORM гальмує навіть з індексами?

Явний SELECT потрібних полів. Ніколи не запитуємо select: ['*'] або порожній масив select:

$result = ProductCatalogTable::getList([
    'select' => ['ID', 'UF_NAME', 'UF_PRICE', 'UF_ACTIVE'],
    'filter' => ['UF_CATEGORY_ID' => $categoryId, 'UF_ACTIVE' => 1],
    'order'  => ['UF_SORT' => 'ASC'],
    'limit'  => 50,
    'offset' => ($page - 1) * 50,
]);

Прямі SQL-запити для агрегації. Для COUNT, SUM, GROUP BY з великими таблицями — прямий SQL в 5–7 разів швидший за ORM. Використовуйте Bitrix\Main\Application::getConnection()->query().

Партиціонування для хронологічних даних. Якщо Highload зберігає логи або події з датою — партиціонування за діапазоном дат різко прискорює вибірки за період:

ALTER TABLE b_hl_event_log
    PARTITION BY RANGE (YEAR(UF_DATE_CREATE) * 100 + MONTH(UF_DATE_CREATE)) (
        PARTITION p_jan VALUES LESS THAN (202402),
        PARTITION p_feb VALUES LESS THAN (202403),
        PARTITION p_future VALUES LESS THAN MAXVALUE
    );

Кешування результатів. Highload-дані добре кешуються через Bitrix\Main\Data\Cache з тегуванням. Приклад реалізації:

class CachedProductCatalog
{
    private const CACHE_TAG = 'hl_product_catalog';
    private const CACHE_TTL = 3600;

    public function getByCategory(int $categoryId): array
    {
        $cache = \Bitrix\Main\Data\Cache::createInstance();
        $cacheKey = 'hl_catalog_cat_' . $categoryId;
        if ($cache->initCache(self::CACHE_TTL, $cacheKey, '/hl/catalog/')) {
            return $cache->getVars();
        }
        $cache->startDataCache();
        // Fetch from DB
        $result = $this->fetchFromDb($categoryId);
        // Тегований кеш
        $tagCache = new \Bitrix\Main\Data\TaggedCache();
        $tagCache->startTagCache('/hl/catalog/');
        $tagCache->registerTag(self::CACHE_TAG . '_' . $categoryId);
        $tagCache->endTagCache();
        $cache->endDataCache($result);
        return $result;
    }
}

Бенчмарки: що дає кожна оптимізація

Покроковий план оптимізації

1. Аудит Highload-блоків. Збір структури, обсягів даних, типових запитів. Включення slow query log.
2. Аналіз вузьких місць. Виявлення топ-5 гальмівних запитів за часом.
3. Додавання індексів. Створення одиночних та складених індексів під реальні фільтри.
4. Рефакторинг коду. Заміна select: ['*'] на явний список, впровадження лімітів та пагінації.
5. Кешування. Впровадження тегованого кешу для часто запитуваних даних.
6. Партиціонування. Для хронологічних таблиць — розбиття за датою.
7. Навантажувальне тестування. AB-порівняння продуктивності до та після.

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

• Аудит Highload-блоків: структура, обсяг даних, типові запити та slow query log.
• Аналіз вузьких місць: виявлення топ-5 гальмівних запитів.
• Додавання індексів: одиночних та складених під реальні патерни фільтрації.
• Рефакторинг коду: явний select, ліміти, пагінація, заміна ORM на прямий SQL там, де це дає суттєвий виграш.
• Впровадження тегованого кешу для важких вибірок.
• Партиціонування хронологічних таблиць (за потреби).
• Навантажувальне тестування з AB-порівнянням до/після.
• Документація та навчання вашого розробника.

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

Терміни робіт: аудит + індекси + кеш — 2–3 тижні. Повна оптимізація з партиціонуванням та рефакторингом — 4–8 тижнів. Вартість розраховується індивідуально в залежності від обсягу даних та складності. Наша команда з багаторічним досвідом у Бітрікс, яка реалізувала понад 50 проектів з оптимізації, гарантує прозорий підхід та вимірювані результати. Зв’яжіться з нами для попередньої оцінки — ми запропонуємо план робіт з контрольними точками. Замовте аудит продуктивності та отримайте консультацію інженера.

Докладніше про Highload-блоки в офіційній документації.

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