Налаштування Redis для кешування в 1С-Бітрікс: практичний посібник

Стандартний кеш Бітрікс записує дані у файли в /bitrix/cache/. На навантаженому сайті з 10 000 відвідувачів на добу це генерує до 300 000 операцій введення-виведення (IOPS). Якщо диск не NVMe, latency зростає, а сторінки завантажуються 3–5 секунд. Ми часто стикаємося з такими проєктами: на одному інтернет-магазині з 50 000 товарів сторінка каталогу відкривалася 4.2 секунди. Після заміни файлового кешу на Redis час упав до 0.6 секунди — в 7 разів швидше, і без зміни коду компонентів. Економія на серверній інфраструктурі може досягати 50% за рахунок зниження навантаження на дискову підсистему. Як зазначається в документації 1С-Бітрікс, "для високонавантажених проєктів критично важливо використовувати кешування in-memory для зниження часу відгуку"Документація 1С-Бітрікс.

Чому Redis, а не файловий кеш?

Redis — in-memory сховище з мікросекундним доступом, документоване в Wikipedia. Він знімає навантаження з дискової підсистеми і дозволяє кешувати набагато більше даних без втрати швидкості. Тегований кеш в Redis працює ефективніше: немає проблеми тисяч дрібних файлів.

Порівняння на типовому проєкті:

Налаштування Redis для кешування в 1С-Бітрікс

Розглянемо покрокове налаштування.

Підключення Redis як кеш-бекенд

У /bitrix/.settings.php додайте або змініть секцію cache:

'cache' => [
    'value' => [
        'type' => [
            'class_name' => '\\Bitrix\\Main\\Data\\CacheEngineRedis',
            'extension'  => 'redis',
        ],
        'sid'  => 'site1',  // унікальний префікс для розділення даних
    ],
],

Налаштування підключення Redis задаються в окремому файлі /bitrix/php_interface/redis.php або через конфігурацію:

// /bitrix/php_interface/init.php
define('BX_CACHE_TYPE', 'redis');
define('BX_CACHE_SID', 'site1');

$GLOBALS['CACHE_REDIS'] = [
    'host'     => '127.0.0.1',
    'port'     => 6379,
    'database' => 2,  // окрема БД від сесій
    'timeout'  => 2,
];

Розділення кешу та сесій

Використовуйте різні бази даних Redis (параметр database):

• БД 0 — службова (RDB persistence)
• БД 1 — сесії
• БД 2 — кеш даних Бітрікс
• БД 3 — кеш HTML-сторінок (якщо використовується)

Це дозволяє очищати кеш незалежно від сесій: redis-cli -n 2 FLUSHDB очистить лише кеш даних.

Конфігурація Redis для кешу даних

# /etc/redis/redis.conf
bind 127.0.0.1
port 6379
maxmemory 1gb
maxmemory-policy allkeys-lru    # витісняти найменш використовувані при нестачі пам'яті
activerehashing yes
tcp-keepalive 300

allkeys-lru — правильна політика для кешу: коли пам'ять заповнюється, витісняються рідко використовувані ключі. Для сесій краще volatile-lru (витісняє лише ключі з TTL).

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

Порівняння популярних політик:

Для кешу даних Бітрікса рекомендуємо allkeys-lru. При нестачі пам'яті витісняються старі, рідко використовувані записи, а гарячі дані залишаються. Докладніше про політики витіснення можна прочитати в Wikipedia.

Тегований кеш в Redis: механізм роботи

Бітрікс використовує тегований кеш для інвалідації груп пов'язаних даних. При зміні елемента інфоблоку тег iblock_id_N інвалідує весь кеш, пов'язаний з цим інфоблоком. Redis зберігає теги ефективніше файлової системи — немає проблеми з тисячами дрібних файлів. Перевірте, що тегований кеш працює:

redis-cli -n 2 KEYS "BITRIX_CACHE_TAG_*" | head -20

Якщо ключів немає — тегований кеш не використовується або дані ще не закешовані.

Розв'язання проблеми низького hit rate

Низький hit rate (нижче 80%) — індикатор проблем. Можливі причини:

• Занадто часті інвалідації: наприклад, кожні 10 секунд змінюється курс валют. Рішення — збільшити TTL або кешувати дані довше.
• Маленький обсяг Redis: якщо виділено 256 МБ, а сайт генерує 1 ГБ кешу, старі ключі витісняються.
• Неправильна політика витіснення: для кешу має бути allkeys-lru, а не noeviction.

Цільовий hit rate — 95%+. Ми в проєктах використовуємо моніторинг в Grafana для відстеження цієї метрики. Якщо ви хочете прискорити свій сайт на Бітріксі, зв'яжіться з нами — ми проведемо аудит і запропонуємо рішення.

Як моніторити продуктивність кешу?

# Статистика використання
redis-cli -n 2 INFO stats | grep -E "keyspace_hits|keyspace_misses"

# Hit rate = hits / (hits + misses)
# Ціль: > 90%

# Кількість ключів
redis-cli -n 2 DBSIZE

# Використання пам'яті
redis-cli INFO memory | grep used_memory_human

Рекомендуємо налаштувати сповіщення при падінні hit rate нижче 85%.

Що входить в роботу з налаштування Redis

При замовленні налаштування Redis під ключ ми надаємо:

1. Аудит поточної конфігурації — перевірка версії Бітрікса, PHP, Redis, аналіз продуктивності.
2. Підготовка Redis-сервера — встановлення, конфігурація з урахуванням навантаження (maxmemory, політика витіснення, персистентність).
3. Інтеграція з Бітрікс — коригування .settings.php та init.php, розділення кешу та сесій на різних базах.
4. Тестування — заміри hit rate, часу генерації сторінок до та після, перевірка тегованого кешу.
5. Документація — опис конфігурації, інструкція з обслуговування, скрипти для моніторингу.
6. Навчання — показуємо, як самостійно відстежувати метрики та очищати кеш.
7. Підтримка — 30 днів гарантії після запуску: відповідаємо на питання, допомагаємо з доналаштуванням.

Терміни — від 2 до 5 днів залежно від складності проєкту. Інвестиції в налаштування Redis окупаються за 1-2 місяці за рахунок зниження навантаження на сервер. Оцінимо ваш проєкт безкоштовно — просто напишіть нам. Замовте налаштування Redis — отримайте консультацію інженера. У нас 5 років досвіду в розробці на 1С-Бітрікс, понад 80 успішних проєктів з прискорення сайтів.

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