Налаштування Redis для кешування сесій 1С-Бітрікс
Уявіть: сайт на Бітрікс з навантаженням 10 000 відвідувачів на годину. Сесії зберігаються у файлах — на кожному запиті PHP зчитує сесію з файлової системи. Якщо серверів кілька, потрібна прив'язка до одного сервера або спільна файлова система NFS, що створює блокування. Ми зіткнулися з цим на проєкті для великого інтернет-магазину: після переходу на Redis час відповіді впав з 2 секунд до 200 мс. При навантаженні 5000 запитів на секунду файлове сховище давало затримки до 50 мс на одну операцію, а Redis обробляв їх за 0.5 мс. У цій статті розповімо, як налаштувати Redis для сесій Бітрікс і уникнути типових помилок.
Чому файлове сховище сесій гальмує проєкт?
Файлові сесії мають три фундаментальні обмеження:
- Масштабування: при зростанні серверів потрібна синхронізація сесій між ними (липкі сесії або спільна ФС). Липкі сесії нерівномірно розподіляють навантаження, а NFS додає затримки.
- Блокування: PHP блокує файл сесії на час запиту, тому паралельні AJAX-запити одного користувача обробляються послідовно. На сторінках з 10+ асинхронними викликами це катастрофічно уповільнює роботу.
- IO-навантаження: при 1000 запитів на секунду дискова підсистема стає вузьким горлом. Пропускна здатність випадкового читання HDD — ~200 IOPS, SSD — до 100 000 IOPS. Redis в пам'яті обробляє мільйони операцій на секунду.
Як Redis вирішує ці проблеми?
Redis — in-memory key-value сховище. Сесії зберігаються в оперативній пам'яті з налаштовуваним TTL. При запиті читання/запис відбувається за мікросекунди. Блокування можна вимкнути (Redis не блокує ключі за замовчуванням). Кілька застосунків можуть одночасно читати сесію, а запис — атомарна операція.
| Критерій | Файлове сховище | Redis |
|---|---|---|
| Швидкість читання (10 000 запитів/с) | ~200 мс | ~1 мс |
| Масштабування | Вимагає NFS або липкі сесії | Централізоване, кластеризується |
| Блокування на читання | Так | Ні (за замовчуванням) |
| Підтримка кластера | Складно | З коробки (Sentinel, Cluster) |
| Споживання пам'яті | Диск + кеш ОС | ОЗП (налаштовується maxmemory) |
Як налаштувати Redis під сесії Бітрікс
Встановлення та базова конфігурація
Встановіть Redis та PHP-розширення:
apt install redis-server php-redis # Ubuntu/Debian yum install redis php-pecl-redis # CentOS/RHEL Базова конфігурація /etc/redis/redis.conf для сесій:
bind 127.0.0.1 port 6379 maxmemory 256mb maxmemory-policy allkeys-lru save "" # відключити персистентність для сесій Підключення PHP-сесій до Redis:
session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=2&prefix=SESS_&database=1" Для Бітрікс сесії керуються через /bitrix/php_interface/dbconn.php або bitrix/.settings.php. Найкращий спосіб — задати параметри через конфігурацію веб-сервера для конкретного віртуального хоста, а не глобально в php.ini.
Налаштування через .settings.php Бітрікс
Бітрікс підтримує кастомні обробники сесій через session секцію в /bitrix/.settings.php:
'session' => [ 'value' => [ 'mode' => 'default', 'handlers' => [ 'general' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'serializer' => \Redis::SERIALIZER_PHP, 'database' => 1, 'ttl' => 86400, ], ], ], ], Перевірка роботи
$redis = new Redis(); $redis->connect('127.0.0.1', 6379); $redis->select(1); $keys = $redis->keys('SESS_*'); echo count($keys) . ' активних сесій'; Також дивіться redis-cli monitor — у реальному часі показує операції з Redis. При нормальній роботі ви побачите GET SESS_<id> при кожному запиті та SET SESS_<id> при зміні сесії.
Важливий нюанс: сесії Бітрікс
Бітрікс зберігає в сесії авторизацію, кошик (для неавторизованих), CSRF-токени. session_write_close() викликається в кінці запиту. Якщо в обробнику є блокування (lock) — при високій конкурентності одного користувача запити вишиковуються в чергу. У більшості випадків це нормально, але для AJAX-важких сторінок варто викликати session_write_close() одразу після читання даних сесії, якщо подальший запис не потрібен.
Як виміряти приріст продуктивності після Redis?
Використовуйте AB-тестування: до і після налаштування заміряйте час відповіді для сторінки з авторизацією. Приклад команди:
ab -n 1000 -c 10 https://yoursite.ru/ Порівняйте середній час запиту. Крім того, дивіться на кількість заблокованих сесій у піку — вона має прагнути до нуля.
Процес роботи
- Аналітика: оцінка поточного навантаження, архітектури, конфігів.
- Проєктування: вибір топології (standalone, sentinel, cluster), розрахунок пам'яті.
- Реалізація: встановлення Redis, налаштування PHP та Бітрікс, міграція сесій.
- Тестування: навантажувальне тестування, перевірка відмовостійкості.
- Деплой: перенесення на продуктив, моніторинг (Redis Dashboard, Grafana).
Що входить в роботу
- Підготовка сервера або контейнера (Docker/Ansible).
- Встановлення та конфігурація Redis під ваше навантаження.
- Інтеграція з Бітрікс через
.settings.php. - Налаштування реплікації та автоматичного failover (опціонально).
- Документація (схема, параметри, рекомендації).
- Навчання команди (1 година).
- Гарантія 30 днів на коректну роботу.
Про наш досвід
Ми — команда сертифікованих спеціалістів з Бітрікс з 7+ роками досвіду. Виконали понад 50 проєктів з оптимізації та масштабування, включаючи налаштування Redis для сесій на проєктах з навантаженням 50 000+ унікальних відвідувачів на добу. Працюємо як з хмарними рішеннями (Бітрікс24), так і з коробковими редакціями.
Зв'яжіться з нами для оцінки вашого проєкту. Замовте налаштування Redis під ключ — отримайте консультацію з архітектури та тестовий запуск без ризику.
Приклад конфігурації для високонавантаженого кластера
Для проєкту з навантаженням 100 000 унікальних відвідувачів на добу використовуйте Sentinel з трьома вузлами:
- Master: maxmemory 1GB, save ""
- Slave: replica-read-only yes
- Sentinel: monitor mymaster 127.0.0.1 6379 2
Детальніше: Redis Sentinel Корисні посилання: Wikipedia: Redis, 1С-Бітрікс







