Профилирование производительности сайта 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 вызовами — цена запрашивалась для каждого элемента отдельно вместо batch-запроса.

Решение: переписать выборку цен через 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 в минуту)

Сроки