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

На одному проекті з каталогом 12 000 товарів агенти пошуку та синхронізації 1С запускалися кожні 30 секунд через hitAgent. Кожен хіт додавав 700 мс до часу відповіді, а раз на 2 хвилини сторінка віддавалася 3 секунди через блокування. У таблиці b_agent накопичилося 400 записів з NEXT_EXEC на тиждень назад. Така ситуація типова для навантажених сайтів на Бітрікс: фонова черга агентів деградує поступово, але в результаті призводить до просідань часу відгуку та зростання навантаження на сервер. Якщо нічого не робити, бізнес втрачає конверсію та відвідувачів через повільні сторінки.

За 5 років роботи ми оптимізували агентів на 50+ проектах — від інтернет-магазинів з 100 000 товарів до корпоративних порталів Бітрікс24. Методика прибирає ці проблеми. Переводимо агентів на cron, чистимо чергу, оптимізуємо важкі завдання та налаштовуємо моніторинг. Результат — стабільний час відгуку без просідань. Інвестиції окупаються за 2–3 місяці. Згідно з офіційним керівництвом Бітрікс, переведення на cron — єдиний спосіб повністю усунути вплив агентів на користувацькі запити. На практиці cron знижує latency в середньому в 3 рази порівняно з hitAgent.

Діагностика поточного стану

Перше, що робимо — дивимося реальну картину в таблиці агентів:

SELECT NAME, ACTIVE, NEXT_EXEC, LAST_EXEC,
       TIMESTAMPDIFF(MINUTE, LAST_EXEC, NOW()) AS minutes_since_last
FROM b_agent
WHERE ACTIVE = 'Y'
ORDER BY NEXT_EXEC ASC;

Агенти з NEXT_EXEC у минулому на кілька годин або днів — це завислі завдання. Вони постійно намагаються запуститися, займають слот виконання та блокують решту агентів у черзі. Так, на одному проекті ми виявили 1200 завислих записів — після чищення час відповіді впав з 2.5 с до 0.8 с.

Друге — дивимося на час виконання важких агентів. Якщо агент пошуку (CSearchIndex::IndexAgent) виконується 45 секунд, а налаштований на запуск щохвилини — він ніколи не завершується коректно та запускається повторно до закінчення попереднього екземпляра. Це призводить до нескінченного циклу та 100% навантаження CPU.

Третє — профілюємо вплив агентів на час відповіді сторінок. Вмикаємо Бітрікс-панель налагодження або логуємо час через \Bitrix\Main\Diag\Debug::startTimeLabel / stopTimeLabel в init.php. Типова картина: 30–50 хітів на хвилину втрачають до 500 мс на виконанні агентів.

Як оптимізація агентів впливає на швидкість сайту?

Після переведення на cron та чищення черги час відгуку сторінок стає стабільним — без періодичних просідань. Навантаження на БД знижується на 20–40% у пікові моменти. Фонові завдання виконуються передбачувано і не залежать від кількості відвідувачів. Детальніше про механізм агентів можна прочитати в офіційній документації та на Wikipedia про cron.

Чи не панацея переведення на cron?

Cron вирішує проблему з блокуванням користувацьких запитів, але не виправляє неефективні агенти самі по собі. Якщо агент виконується 30 секунд і робить це кожні 2 хвилини, він просто перевантажує сервер вже поза веб-хітами. Важно:

• проаналізувати кожен важкий агент;
• розбити тривалі завдання на пакети;
• налаштувати пріоритети та моніторинг.

Ось таблиця типових важких агентів та їх оптимізація:

Переведення агентів на cron: покрокова інструкція

1. У файлі /bitrix/.settings.php або через адміністративний інтерфейс (Налаштування → Продуктивність) вкажіть:

   'agents' => [
       'value' => [
           'pull_agent_manager' => 'cron',
       ],
   ],
   

2. У crontab додайте:

   */1 * * * * /usr/bin/php -f /var/www/bitrix/bitrix/modules/main/tools/cron_events.php > /dev/null 2>&1
   

3. Перевірте, що cron запускається (додайте запис у лог).
4. Налаштуйте моніторинг виконання (див. нижче).

Після переведення на cron агенти більше не виконуються в контексті веб-запитів. Час відповіді сторінок вирівнюється, зникають характерні «провали» на графіку latency кожні N секунд. Важливий нюанс: агент пошуку CSearchIndex::IndexAgent при роботі через cron може конкурувати з PHP-FPM за CPU. Виносимо його в окремий cron-скрипт з nice -n 10 та обмеженням за часом через timeout.

Оптимізація черги та пріоритетів

Після переведення на cron розбираємо накопичений борг:

• Чищення завислих агентів. Агенти з NEXT_EXEC старше доби і без успішного LAST_EXEC за останні 48 годин — кандидати на деактивацію або перестворення. Для кожного уточнюємо: чи живий модуль, чи існує функція, чи є винятки в логах.
• Оптимізація інтервалів. CSearchIndex::IndexAgent з інтервалом 30 секунд при реальному часі виконання 20 секунд — розклад на катастрофу. Перераховуємо інтервали виходячи з реального часу роботи + буфер 50%.
• Рознесення важких агентів. Якщо кілька важких агентів (синхронізація з 1С, відправка email-розсилок, перерахунок цін) налаштовані на запуск одночасно — розносимо їх старт через NEXT_EXEC з інтервалом 5–10 хвилин.
• Моніторинг виконання. Додаємо логування в кастомні агенти:

function MyHeavyAgent(): string
{
    $start = microtime(true);
    // ... логіка ...
    $elapsed = microtime(true) - $start;
    if ($elapsed > 10) {
        \Bitrix\Main\Diag\Debug::writeToFile(
            "MyHeavyAgent took {$elapsed}s",
            '',
            '/bitrix/logs/agent_performance.log'
        );
    }
    return 'MyHeavyAgent();';
}

Налаштування моніторингу агентів

Додаємо в Zabbix/Prometheus метрику кількості завислих агентів:

SELECT COUNT(*) as stuck_agents
FROM b_agent
WHERE ACTIVE = 'Y'
  AND NEXT_EXEC < DATE_SUB(NOW(), INTERVAL 1 HOUR);

Якщо значення > 0 протягом більше 30 хвилин — алерт в Telegram/Slack. Це ранній індикатор проблем з cron або перевантаження сервера. Наприклад, на одному проекті алерт спрацював при 50 завислих агентах — після аналізу з'ясувалося, що cron не запускався через помилку в crontab.

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

• Аудит поточного стану зі звітом по кожному агенту (кількість, час виконання, інтервал).
• Переведення на cron з індивідуальним розкладом.
• Оптимізація важких агентів (кешування, пакетна обробка).
• Налаштування моніторингу (Zabbix/Prometheus, алерти в Telegram).
• Інструкція з подальшого обслуговування та рекомендації.
• Гарантія 90 днів на результат.

Результат і гарантія

Переведення на cron та оптимізація черги агентів прибирають періодичні просідання часу відповіді, знижують навантаження на БД у пікові моменти на 20–40%, забезпечують передбачуване виконання фонових завдань без впливу на користувацькі запити. Вартість послуги розраховується індивідуально — отримайте консультацію, ми безкоштовно оцінимо поточний стан ваших агентів і запропонуємо план оптимізації. Замовте аудит вже сьогодні.

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