Стандартний кеш Бітрікс записує дані у файли в /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–5 мс (HDD) / 100–500 мкс (SSD) | 50–100 мкс |
| Максимальна кількість запитів | ~500 IOPS (HDD) | 50 000+ операцій/с |
| Зберігання тегованого кешу | Дрібні файли, очищення директорій | Ефективні теги, швидка DEL |
| Споживання пам'яті | Залежить від ФС | Контролюється через maxmemory |
Налаштування 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
Для зберігання сесій в Redis додайте в `init.php`: ```php ini_set('session.save_handler', 'redis'); ini_set('session.save_path', 'tcp://127.0.0.1:6379?database=1&prefix=SESS_'); ``` А в конфігурації Redis для сесій використовуйте політику `volatile-lru`: ```ini maxmemory-policy volatile-lru ```Конфігурація 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 |
Витісняє найменш використовувані ключі серед усіх | Для кешу даних |
volatile-lru |
Витісняє LRU серед ключів з TTL | Для сесій |
noeviction |
Повертає помилку при заповненні | Тільки якщо впевнені в об'ємі |
allkeys-lfu |
Витісняє найменш часто використовувані | Якщо доступ до даних нерівномірний |
Для кешу даних Бітрікса рекомендуємо 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 під ключ ми надаємо:
- Аудит поточної конфігурації — перевірка версії Бітрікса, PHP, Redis, аналіз продуктивності.
- Підготовка Redis-сервера — встановлення, конфігурація з урахуванням навантаження (maxmemory, політика витіснення, персистентність).
- Інтеграція з Бітрікс — коригування
.settings.phpтаinit.php, розділення кешу та сесій на різних базах. - Тестування — заміри hit rate, часу генерації сторінок до та після, перевірка тегованого кешу.
- Документація — опис конфігурації, інструкція з обслуговування, скрипти для моніторингу.
- Навчання — показуємо, як самостійно відстежувати метрики та очищати кеш.
- Підтримка — 30 днів гарантії після запуску: відповідаємо на питання, допомагаємо з доналаштуванням.
Терміни — від 2 до 5 днів залежно від складності проєкту. Інвестиції в налаштування Redis окупаються за 1-2 місяці за рахунок зниження навантаження на сервер. Оцінимо ваш проєкт безкоштовно — просто напишіть нам. Замовте налаштування Redis — отримайте консультацію інженера. У нас 5 років досвіду в розробці на 1С-Бітрікс, понад 80 успішних проєктів з прискорення сайтів.