Налаштування панелі продуктивності Бітрікс: діагностика та оптимізація

Коли сайт на Бітрікс починає гальмувати — клієнти скаржаться, менеджери нервують, а в адмінці кожен клік чекаєш по 10 секунд?

Перший інструмент, який має освоїти кожен розробник — вбудована панель продуктивності. Ми за 8 років на ринку та 50+ проєктах по Бітрікс не раз переконувалися: її даних вистачає для 80% завдань діагностики без зовнішніх профайлерів. Нещодавно до нас звернувся інтернет-магазин з каталогом 50 000 товарів — сторінка каталогу вантажилася 12 секунд. Після налаштування панелі та оптимізації SQL час упав до 1.2 секунди, економія в 10 разів — що в перерахунку на хостинг зекономило клієнту 75 000 грн щомісяця. Такі результати типові, коли знаєш, на що дивитися. Нижче розберемо, як налаштувати панель, інтерпретувати її показники та провести реальну оптимізацію.

Ввімкнення панелі продуктивності

Активується через адміністративний інтерфейс: Налаштування → Продуктивність → Панель продуктивності. Для швидкого налагодження можна ввімкнути програмно:

// Показувати панель для поточного користувача $USER->SetShowStatPanel(true); // Або в dbconn.php для налагодження на dev-оточенні define('BX_STATPANEL', true); 

Панель видно лише авторизованим користувачам у групі «Адміністратори». На production її варто тримати ввімкненою лише при активному налагодженні — вона сама додає невелике навантаження на збір даних. Згідно з офіційною документацією Бітрікс, панель не впливає на швидкість сторінки для звичайних відвідувачів.

Показники панелі продуктивності

• Час виконання — повний час PHP + SQL у мілісекундах. Розбивка: PHP-час і час очікування MySQL.
• Запити до БД — кількість SQL-запитів та їх сумарний час. Клацніть на блок — відкриється список усіх запитів із часом виконання кожного.
• Кеш — кількість звернень до кешу: hits (влучень) і misses (промахів). Низький hit rate (< 80%) — сигнал, що кеш неефективно налаштований або занадто часто інвалідується.
• Файли — кількість підключених PHP-файлів. 500+ файлів без OPcache — це повільна ініціалізація.
• Пам'ять — пікове споживання пам'яті PHP-скриптом. 64 МБ+ — варто перевірити, чи немає витоків або надмірних завантажень даних.

Для зручності зведемо нормальні значення в таблицю:

Типові проблеми та їх рішення зібрані в таблиці нижче.

Детальне профілювання SQL

Клацніть на блок SQL у панелі — відкриється список усіх запитів. Сортуйте за часом. Запити > 50 мс — кандидати на оптимізацію через EXPLAIN. Запити, що повторюються 10+ разів з однаковим шаблоном — N+1 проблема. Зазвичай це властивості елементів інфоблоку, що запитуються поелементно. Порівняння: правильно побудований запит з одним JOIN працює в 10-20 разів швидше, ніж N окремих запитів.

Налаштування монітора продуктивності

У меню Налаштування → Продуктивність → Монітор продуктивності задайте:

• Поріг запису в лог — 1000 мс для production, 500 мс для staging
• Зберігати записів — 1000–5000 записів у таблиці b_perf_hit
• Записувати SQL — увімкніть, щоб бачити список запитів для повільних сторінок

Перегляд логу: Налаштування → Продуктивність → Перегляд логу. Сортуйте за сумарним часом SQL — там будуть найпроблемніші сторінки.

Алгоритм діагностики конкретної проблеми

1. Відкрити повільну сторінку з увімкненою панеллю.
2. Подивитися співвідношення PHP-час / SQL-час. Якщо SQL > 70% — оптимізуємо запити. Якщо PHP-час великий при невеликому SQL — проблема в коді компонентів.
3. Відкрити список SQL-запитів, відсортувати за часом.
4. Скопіювати повільний запит, запустити EXPLAIN у MySQL Workbench або phpMyAdmin. Часто допомагає додавання індексу — час запиту падає в 5-10 разів.
5. Додати відсутній індекс, оновити сторінку, переконатися в покращенні.

Типова ситуація: на одному з проєктів сторінка каталогу вантажилася 8 секунд. Панель показала 250 SQL-запитів. EXPLAIN виявив відсутність індексів по полю IBLOCK_SECTION_ID. Після додавання індексу сторінка стала вантажитися за 0.8 секунди — покращення в 10 разів.

Чому панель продуктивності не завжди достатня?

Панель чудово виявляє повільні SQL-запити та проблеми кешування, але не показує вузькі місця в асинхронному коді або зовнішніх API-викликах. Для глибокої діагностики ми додатково використовуємо Xdebug-профілювання та моніторинг у бік REST-сервісів (наприклад, 1С або платіжних шлюзів). Панель — перший ешелон діагностики, але не останній.

Як часто потрібно проводити аудит продуктивності?

Рекомендуємо запускати монітор продуктивності постійно, а розгорнутий аудит проводити раз на квартал або після великих оновлень. Це дозволяє виявляти деградацію на ранніх стадіях. Наприклад, після додавання нового розділу каталогу або інтеграції з новим API варто перевірити, чи не збільшилася кількість SQL-запитів.

Склад повного аудиту продуктивності

Якщо довірити діагностику нам, ви отримуєте:

• Повний аудит поточної продуктивності з використанням панелі та додаткових інструментів.
• Оптимізацію SQL-запитів: аналіз EXPLAIN, додавання індексів, рефакторинг ORM-запитів.
• Налаштування кешування: тегований кеш, HTML-кеш, композитний режим.
• Конфігурацію монітора продуктивності для постійного збору метрик.
• Підсумковий звіт з рекомендаціями та планом дій.
• Гарантію на результат — зафіксуємо цільові показники часу завантаження.

Середня економія після нашого аудиту становить 50 000-100 000 грн на місяць на інфраструктурних витратах. Замовте попередню безкоштовну діагностику за панеллю продуктивності. Зв'яжіться з нами для консультації щодо оптимізації.

SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME, NON_UNIQUE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'your_database';