Оптимізація MySQL/MariaDB під навантаження Бітрікс

Дефолтна конфігурація MySQL після встановлення розрахована на сервер з 256 МБ RAM. Бітрікс на реальному магазині — це тисячі запитів за хвилину до b_iblock_element, b_sale_order, b_catalog_price. Без налаштування my.cnf сервер працює з буферними пулами в 128 МБ при 16 ГБ доступної пам'яті, робить дискові I/O там, де має читати з кешу, і тримає пул з'єднань на рівні, що викликає черги при піковому навантаженні.

Ми провели десятки аудитів для інтернет-магазинів на Бітрікс: у 90% випадків дефолтна конфігурація призводила до падінь latency при 100+ одночасних замовленнях. Наш досвід — 10+ років у бітрікс-розробці, 50+ проєктів з оптимізації БД. Компанія працює на ринку з 2015 року. Пропонуємо послугу під ключ: від діагностики до фінального тюнінгу з гарантією покращення продуктивності. Детальніше про MySQL та MariaDB.

Вартість аудиту — від $500, комплексна оптимізація — від $1500. Середня економія на серверних ресурсах після впровадження — до $2000 на місяць.

Оптимізація MySQL для Бітрікс: покроковий підхід

Процес включає аудит поточних налаштувань, розрахунок параметрів під навантаження вашого магазину, тестування на staging та поетапне впровадження на production. Ми використовуємо стандартні утиліти: mysqltuner.pl, pt-variable-advisor, та моніторинг через SHOW GLOBAL STATUS. Після змін проводимо повторний замір метрик — hit rate буферного пулу має бути вище 99%, тимчасові таблиці на диску — відсутні.

Ключові параметри конфігурації

# InnoDB Buffer Pool
innodb_buffer_pool_size = 12G          # 70-75% RAM
innodb_buffer_pool_instances = 8
innodb_buffer_pool_chunk_size = 128M

# InnoDB Log
innodb_log_file_size = 1G
innodb_log_buffer_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT

# Connections
max_connections = 300
thread_cache_size = 64
table_open_cache = 4000
table_definition_cache = 2000

# Temporary tables
tmp_table_size = 256M
max_heap_table_size = 256M

# Slow queries
slow_query_log = 1
long_query_time = 0.5
log_queries_not_using_indexes = 1
min_examined_row_limit = 1000

Налаштування InnoDB Buffer Pool

InnoDB Buffer Pool — найважливіший параметр. Має вміщувати робочий набір даних цілком. На виділеному сервері БД встановлюємо 70–75% RAM. Правило: якщо hit rate буферного пулу (дивимось через SHOW GLOBAL STATUS) нижче 99%, значить пам'яті не вистачає. Збільшуємо до 80% RAM, але не більше 90%, щоб залишити місце ОС. Враховуйте mutex contention: при великій кількості потоків розбивайте пул на інстанси (innodb_buffer_pool_instances).

InnoDB Log та flush

Для Бітрікс з інтенсивними записами (замовлення, сесії, агенти): innodb_log_file_size = 1G, innodb_log_buffer_size = 64M. innodb_flush_log_at_trx_commit = 2 дає до 30% приросту продуктивності при записі ціною втрати даних останньої секунди при жорсткому падінні сервера — для більшості e-commerce сайтів це прийнятно. Якщо є суворі вимоги щодо ACID (фіскальні операції) — залишаємо значення 1.

Чому важливе налаштування тимчасових таблиць?

Розумний фільтр та пошук Бітрікс активно створюють тимчасові таблиці. Якщо тимчасова таблиця не вміщується в пам'ять — MySQL пише її на диск (spill to disk), що сповільнює запит у 10–50 разів. Моніторимо через SHOW GLOBAL STATUS LIKE 'Created_tmp_disk_tables'. Якщо значення зростає — збільшуємо розміри.

З'єднання та потоки

Бітрікс використовує постійні з'єднання через PHP-FPM. При 20 воркерах PHP-FPM і пулі в 10 процесів кожен — 200 одночасних з'єднань із запасом. Ставити max_connections = 1000 без потреби — резервувати RAM під невикористовувані thread stacks.

Специфіка MariaDB

MariaDB 10.4+ має ряд параметрів, відсутніх у MySQL:

innodb_adaptive_hash_index_parts = 8
aria_pagecache_buffer_size = 512M      # для MyISAM/Aria таблиць сесій

Бітрікс за замовчуванням зберігає PHP-сесії у файлах, але при використанні сесій у БД або модуля bitrix.session таблиці сесій можуть бути MyISAM — враховуємо це при налаштуванні.

Рекомендовані значення для різних об'ємів RAM

Порівняння: дефолт vs оптимізація

Оптимізована конфігурація дає час відповіді в 6–7 разів швидше за дефолтну: hit rate буферного пулу піднімається з 60% до 99.9%, тимчасові таблиці на диску зникають, середній час запиту падає з 200 мс до 30 мс. Таким чином, оптимізований сервер працює в 5-7 разів швидше за дефолтний. Для типових запитів каталогу швидкість зросла в 3-5 разів.

Процес роботи

1. Аудит поточної конфігурації за допомогою mysqltuner.pl та pt-variable-advisor, аналіз SHOW GLOBAL STATUS.
2. Розрахунок параметрів під ваш сервер: RAM, CPU, навантаження, дискова підсистема.
3. Застосування змін на staging з навантажувальним тестуванням.
4. Розгортання на production у вікно технічного обслуговування.
5. Моніторинг після змін через Zabbix/Prometheus + mysqld_exporter.

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

1. Аудит конфігурації та slow query log аналіз.
2. Надання документації з рекомендаціями.
3. Повний доступ до сервера на час робіт.
4. Навчання команди моніторингу.
5. Підтримка протягом 30 днів після впровадження.

Результат оптимізації MySQL для Бітрікс

Коректна конфігурація MySQL під Бітрікс знижує середній час відповіді БД на 40–70%, прибирає піки latency при конкурентних запитах, знижує дисковий I/O на сервері в 2–5 разів.

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

— Рекомендації з налаштування продуктивності MySQL в документації Oracle (InnoDB Startup Options).

Ключові метрики нашої компанії: понад 10 років досвіду в оптимізації БД, 50+ успішних проєктів, з 2015 року на ринку. Середня економія клієнтів на серверних ресурсах — $2000/міс.

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