Configuring Redis for Session Caching in 1C-Bitrix
By default, PHP stores sessions in files on disk. With high traffic or multiple servers behind a load balancer, this creates problems: the file system doesn't scale, and a single user's sessions should be routed to one server. Redis solves both issues.
Installing and Basic Redis Configuration
Install Redis and the PHP extension:
# Ubuntu/Debian
apt install redis-server php-redis
# CentOS/RHEL
yum install redis php-pecl-redis
Basic configuration in /etc/redis/redis.conf for sessions:
bind 127.0.0.1
port 6379
maxmemory 256mb
maxmemory-policy allkeys-lru
save "" # disable persistence for sessions
Connecting PHP Sessions to Redis
In php.ini or the site configuration file:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=2&prefix=SESS_&database=1"
Parameters in save_path: timeout — connection timeout in seconds, prefix — key prefix for isolation from other data, database — Redis database number (0–15).
For Bitrix, sessions are managed via /bitrix/php_interface/dbconn.php or bitrix/.settings.php. The best approach is to set parameters through the web server configuration for a specific virtual host, not globally in php.ini.
Configuration via Bitrix .settings.php
Bitrix supports custom session handlers via the session section in /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,
],
],
],
],
Verification
// Check that sessions are stored in Redis
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->select(1);
$keys = $redis->keys('SESS_*');
echo count($keys) . ' active sessions';
Also use redis-cli monitor — shows Redis operations in real-time. Under normal conditions, you'll see GET SESS_<id> on each request and SET SESS_<id> when the session changes.
Important Note: Bitrix Sessions
Bitrix stores authentication, cart (for unauthenticated users), and CSRF tokens in sessions. session_write_close() is called at the end of the request. If there are locks in the handler—under high concurrency, a single user's requests may queue. In most cases this is normal, but for AJAX-heavy pages, consider calling session_write_close() immediately after reading session data if further writes aren't needed.