Профілювання продуктивності сайту 1С-Бітрікс

Профілювання продуктивності сайту 1С-Бітрікс

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

Рівні профілювання

Продуктивність Бітрікс-проєкту деградує на кількох рівнях одночасно, і кожен потребує власного інструментарію:

Починаємо завжди з браузерного рівня — він показує симптом. Потім спускаємося до PHP, далі до СУБД.

Вбудоване профілювання Бітрікс

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

// Вмикається в /bitrix/admin/settings.php → Продуктивність
// або програмно:
define('BX_DEBUG', true);
define('SHOW_SQLS', true); // показує всі SQL-запити

У нижній частині сторінки з'являється панель із:

• часом генерації сторінки
• кількістю SQL-запитів та сумарним часом
• кількістю підключених файлів
• статистикою кешу (hit/miss)

На що звертати увагу: якщо SQL-запитів > 100 або сумарний SQL-час > 1 с — проблема в базі даних. Якщо запитів мало, але час генерації великий — проблема в PHP-коді (важкі обчислення, повільні зовнішні API).

XHProf: граф викликів PHP

Для детального профілювання PHP встановлюємо XHProf або його форк Tideways:

# Ubuntu/Debian
apt install php8.1-xhprof

# php.ini або 90-xhprof.ini
extension=xhprof.so
xhprof.output_dir=/var/tmp/xhprof

Запускаємо профілювання через local/php_interface/init.php:

if (isset($_GET['__profile']) && $_SERVER['REMOTE_ADDR'] === '127.0.0.1') {
    xhprof_enable(XHPROF_FLAGS_CPU | XHPROF_FLAGS_MEMORY);

    register_shutdown_function(function () {
        $data = xhprof_disable();
        $dir  = '/var/tmp/xhprof';
        $run  = uniqid();
        file_put_contents("$dir/$run.xhprof", serialize($data));
        // Посилання на звіт
        error_log("XHProf: /xhprof/index.php?run=$run&source=bitrix");
    });
}

Додаємо ?__profile=1 до URL (тільки з локального IP). Результат — граф викликів з часом кожної функції. Шукаємо функції з високим inclusive time (сумарний час включно з викликаними з них) — це кандидати на оптимізацію.

Blackfire: промислове профілювання

Blackfire.io — комерційний профілювальник, що працює без змін коду та доступний для production:

# Встановлення агента
curl -sSL https://packages.blackfire.io/gpg.key | apt-key add -
apt install blackfire-agent blackfire-php

# Профілювання URL
blackfire curl https://example.com/catalog/

Blackfire будує граф викликів з агрегацією по 10 запитах (усуває шум), показує гарячі шляхи та пропонує рекомендації. Особливо корисний для проєктів з Бітрікс D7 — добре видно ланцюжки викликів через \Bitrix\Main\ORM.

Профілювання компонентів Бітрікс

Іноді вузьке місце — конкретний компонент. Вимірюємо його час:

$start = microtime(true);

$APPLICATION->IncludeComponent('bitrix:catalog.section', '.default', [
    'IBLOCK_ID' => 5,
    'CACHE_TYPE' => 'A',
    'CACHE_TIME' => 3600,
    // ...
]);

$elapsed = round((microtime(true) - $start) * 1000, 2);
// Логуємо, якщо повільніше за поріг
if ($elapsed > 200) {
    \Bitrix\Main\Diag\Debug::writeToFile(
        "catalog.section: {$elapsed}ms",
        'SLOW_COMPONENT',
        '/local/logs/performance.log'
    );
}

\Bitrix\Main\Diag\Debug::writeToFile() — штатний спосіб логування в Бітрікс. Не використовує error_log і не засмічує системні логи.

Аналіз ефективності кешу

Бітрікс використовує кілька рівнів кешу: файловий (/bitrix/cache/), memcached/Redis, HTML-кеш сторінок. Ефективність:

// Статистика кешу через API
$cacheManager = \Bitrix\Main\Application::getInstance()->getManagedCache();
// Для memcached: дивимось stats через telnet
// telnet localhost 11211
// stats
// Hits, misses, evictions — ключові показники

Якщо get_misses близьке до get_hits — кеш майже не працює. Причини: занадто короткий TTL, часте скидання при оновленні даних, кеш по $_SERVER['REQUEST_URI'] без урахування кукі.

Кейс: дистриб'ютор FMCG

B2B-портал на Бітрікс «Бізнес», каталог з 85 000 позицій, персоналізовані ціни за групами контрагентів. Скарга: сторінка каталогу завантажується 8–12 с.

Діагностика через Бітрікс-дебагер: 340 SQL-запитів, сумарний час 4,8 с. XHProf вказав на CPrice::GetBasePrice() з 340 викликами — ціна запитувалася для кожного елемента окремо замість пакетного запиту.

Рішення: переписати вибірку цін через CCatalogProductPrice::GetList() з фільтром за масивом ID:

$priceResult = \Bitrix\Catalog\PriceTable::getList([
    'filter' => ['PRODUCT_ID' => $productIds, 'CATALOG_GROUP_ID' => $userGroupId],
    'select' => ['PRODUCT_ID', 'PRICE', 'CURRENCY'],
]);
$prices = [];
while ($price = $priceResult->fetch()) {
    $prices[$price['PRODUCT_ID']] = $price;
}

Результат: 340 запитів → 1 запит за цінами, час генерації: 9 с → 0,8 с. Також увімкнули HTML-кеш компонента з тегованим скиданням через CACHE_GROUPS.

Безперервний моніторинг продуктивності

Разове профілювання не захищає від регресій. Налаштовуємо baseline:

• New Relic APM або Datadog — агент PHP, метрики в реальному часі
• Бітрікс Monitor (модуль monitor) — вбудований моніторинг зі збереженням історії
• Алерти в Telegram/Email при перевищенні порогів (час відповіді > 2 с, помилки 500 > N на хвилину)

Терміни