bitrix-performance

name

bitrix-performance

description

Эксперт по производительности и highload 1С-Битрикс (сайты/интернет-магазины на больших объёмах: сотни тысяч товаров, высокий трафик). Используй всякий раз, когда сайт на Битрикс тормозит/зависает/растёт нагрузка; когда проектируешь производительный код (кэш, запросы, каталог на объёмах); когда разбираешь «почему медленно» (Монитор производительности, лог медленных страниц, EXPLAIN, xhprof); когда настраиваешь кэш-слои (компонентный, тегированный, композит, Redis), оптимизируешь CIBlockElement::GetList / D7 ORM, ловишь N+1, работаешь с фасетным индексом умного фильтра, тюнингуешь MySQL/OPcache/PHP-FPM, масштабируешь (веб-кластер). Срабатывай даже без слов «производительность», если речь о том, почему медленно/не масштабируется. Железное правило: источник истины — ИЗМЕРЕНИЕ (perfmon, счётчики, план запроса, slow log), а НЕ память модели; сначала сними замер — потом вывод. Написание кода — скилл bitrix-dev; анализ задачи — bitrix-analyst.

Производительность 1С-Битрикс — сначала замер, потом вывод

Аналог 1c-expert, но для Битрикс. Не оптимизируй вслепую. Порядок: снять данные → локализовать → починить → перезамерить. Глубокие материалы по разделам — references/.

Правило №0: источник истины — измерение

Сначала: панель отладки (для админа) → Монитор производительности (замер под нагрузкой) → лог медленных страниц → EXPLAIN тяжёлых SQL / xhprof. Только потом — гипотеза и фикс. Непроверенное помечай [проверить].

Быстрый чек-лист «Битрикс тормозит» (по порядку)

1. Панель отладки внизу страницы: время генерации, память, число SQL-запросов, число компонентов. Сотни запросов → N+1 или отключённый кэш.
2. Монитор производительности → замер под нагрузкой → топ нагруженных страниц + APDEX. Начинай с топа.
3. Лог медленных страниц → худшие URL.
4. Кэш: у медленной страницы включён кэш компонента? CACHE_TYPE=N/CACHE_TIME=0? Автокэширование выключено глобально?
5. SQL: slow query log + EXPLAIN → нет индекса / full scan / тяжёлый JOIN фасета.
6. xhprof на проде в пик → что ест время (PHP vs SQL vs внешний API).
7. Инфраструктура: OPcache вкл.? Кэш в Redis/memcached, не файлы? innodb_buffer_pool_size адекватен? «Проверка системы» Битрикс — всё зелёное?

Локализация:

• «Одна страница медленно» → панель отладки: много SQL → N+1/кэш; мало SQL но долго → PHP (xhprof) или один тяжёлый SQL (EXPLAIN).
• «Весь сайт под нагрузкой» → инфра: OPcache, хранилище кэша, innodb_buffer_pool, PHP-FPM max_children, CPU/IO.
• «После релиза» → холодный кэш (норма первые минуты) либо новый код в init.php/обработчике. Сравни perfmon до/после.
• «Фильтр/каталог» → фасетный индекс, объём b_iblock_element_property, число свойств/типов цен.

Кэш — первое оружие (разница 10-100× по времени генерации)

• Компоненты: $this->startResultCache() → setResultCacheKeys([...]) (только нужные шаблону ключи) → includeComponentTemplate(). CACHE_TIME, CACHE_TYPE (A/Y/N), CACHE_GROUPS (Y — если контент зависит от прав).
• D7 произвольные данные: Bitrix\Main\Data\Cache::createInstance() → initCache/startDataCache/endDataCache.
• Тегированный кэш: Application::getInstance()->getTaggedCache() + registerTag('iblock_id_17') — автосброс при изменении инфоблока. Требует включённого управляемого кэша. HL-блоки тег НЕ сбрасывают — чисти вручную из обработчика.
• Композит (Composite): мгновенная статика + AJEX-догрузка персонального. Только GET; персональные блоки ОБЯЗАТЕЛЬНО оборачивать (иначе утечка цен/имён/корзины в общий кэш). Ломается от RestartBuffer()/незакрытого вывода/ошибок PHP.
• Хранилище кэша — на нагрузке переключить с файлов на Redis (стабильнее memcached, кластер) в .settings.php.
• Не кэшировать общим кэшем: корзину, авторизацию, персональные цены/скидки — только композит-динамика или AJAX.

Детали, код и подводные камни — references/caching.md.

Запросы и данные

• CIBlockElement::GetList: явный select (только нужные поля; не тащить все PROPERTY_*), filter по индексам (IBLOCK_ID,ACTIVE,SECTION_ID,ID), свойства грузить пакетно, счётчик — SetRowCount/отдельный лёгкий запрос.
• D7 ORM: *Table::getList(['select','filter','order','limit','count_total'=>true,'cache'=>['ttl'=>3600,'cache_joins'=>true]]); join через точку; агрегаты — ExpressionField + registerRuntimeField.
• N+1 (запрос в цикле) — главный анти-паттерн: собери ID → один запрос IN(...); свойства/разделы предзагружай пакетно.
• Прямой $DB->Query — только для тяжёлых агрегатов/batch; экранируй $DB->ForSql()/каст (иначе SQL-инъекция); теряешь тегированный сброс.

Детали и примеры — references/queries-and-orm.md.

Объёмы (интернет-магазин)

• Инфоблоки 2.0 (свойства-колонки вместо EAV) при 50K+ товаров; после миграции — вручную создавать индексы MySQL на связующие колонки.
• Фасетный индекс умного фильтра ускоряет фильтрацию, но деградирует > 10 млн записей фасета (тяжёлые JOIN); каждый тип цены и множественное свойство SKU удваивают нагрузку.
• Highload-блоки для больших справочников/характеристик (без оверхеда b_iblock_element_property).
• 1М+ SKU → свойства в HL + инфоблоки 2.0; поиск/фильтр выносить в ElasticSearch/OpenSearch/Meilisearch.

Детали, формулы объёма, тайминги — references/large-catalogs.md.

Инфраструктура

• OPcache обязателен (max_accelerated_files 100000+, validate_timestamps=0 на проде с деплой-инвалидацией).
• Redis/memcached как хранилище кэша (.settings.php секция cache).
• MySQL/MariaDB: innodb_buffer_pool_size 70-80% RAM (главный), transaction-isolation=READ-COMMITTED (требование Битрикс), innodb_flush_log_at_trx_commit=2, innodb_log_file_size 256-512M. Валидируй «Панелью проверки системы».
• PHP-FPM: pm.max_children по памяти, pm.max_requests против утечек.
• Веб-кластер (highload): репликация master-slave, общий Redis-пул, синхронизация сессий/файлов, балансировка.

Детали — references/infrastructure.md.

Диагностические инструменты

• Монитор производительности (perfmon): тест конфигурации + замер под нагрузкой (топ страниц, APDEX, SQL vs PHP).
• Панель отладки + \Bitrix\Main\Diag\Debug::writeToFile() для замера участков.
• xhprof + XHGui (прод в пик), Blackfire/Tideways (APM), slow query log + EXPLAIN.
• Отладка в dbconn.php ($DBDebug) / .settings.php (exception_handling.debug — на проде false).

Детали — references/diagnostics.md.

Качество = производительность: статически ловим анти-паттерны (ДО прода)

Проактивный слой (ast-grep / PHPStan-правила toolkit, см. core/linters/ (в репозитории toolkit)):

• Запрос в цикле (GetList/getList/$DB->Query/GetProperty внутри while/for/foreach) → N+1.
• GetList без явного select на списках → выбор всех полей.
• Компонент с CACHE_TYPE=>'N' в IncludeComponent(...) → кэш отключён, требует ревью.
• SELECT * и конкатенация переменной в $DB->Query.
• Тяжёлые вызовы в init.php/dbconn.php (GetList/HTTP/file_get_contents(http...)) — на каждом хите. Это прямой аналог того, как 1c-скилл ловит «запрос в цикле» в BSL. Правила — в core/linters/ast-grep/ (в репозитории toolkit).

Шпаргалка

1. Всегда сначала замер. 2. Кэш (компонент → тег iblock_id_* → композит → Redis). 3. Запросы: явный select, индексы, никаких N+1, ORM с cache. 4. Объёмы: инфоблоки 2.0 + индексы при 50K+, фасет деградирует >10 млн, 1М+ → Elastic+HL.
2. Инфра: OPcache, Redis, buffer_pool 70-80%, проверка системы зелёная. 6. Анти-паттерны ловить статически.