Redis Session Caching for 1C-Bitrix: Complete Optimization Guide

Imagine: a Bitrix site with a load of 10,000 visitors per hour. Sessions are stored in files — on each request, PHP reads the session from the file system. If there are multiple servers, you need sticky sessions or a shared NFS file system, which creates locks. We encountered this on a project for a

Our competencies:

Frequently Asked Questions

Imagine: a Bitrix site with a load of 10,000 visitors per hour. Sessions are stored in files — on each request, PHP reads the session from the file system. If there are multiple servers, you need sticky sessions or a shared NFS file system, which creates locks. We encountered this on a project for a large e-commerce store: after switching to Redis, response time dropped from 2 seconds to 200 ms (a 90% reduction). Under a load of 5000 requests per second, file storage gave delays up to 50 ms per operation, while Redis processed them in 0.5 ms (100x faster). In this article, we'll explain how to configure Redis for Bitrix sessions and avoid common mistakes.

Why file-based session storage slows down your project?

File-based sessions have three fundamental limitations:

  • Scaling: with more servers, session synchronization is required (sticky sessions or shared FS). Sticky sessions distribute load unevenly, while NFS adds delays.
  • Locking: PHP locks the session file for the duration of the request, so parallel AJAX requests from the same user are processed sequentially. On pages with 10+ asynchronous calls, this dramatically slows down performance.
  • I/O load: at 1000 requests per second, the disk subsystem becomes a bottleneck. Random read throughput of HDD is ~200 IOPS, SSD up to 100,000 IOPS. Redis in memory handles millions of operations per second.
  • Redis is 100x faster than file storage for session operations, making it ideal for site acceleration and session cluster setups.

How Redis solves these problems?

Redis is an in-memory key-value store. Sessions are stored in RAM with configurable TTL. Read/write operations take microseconds. Locking can be disabled (Redis does not lock keys by default). Multiple applications can read the session simultaneously, and writes are atomic.

Criterion File storage Redis
Read speed (10,000 req/s) ~200 ms ~1 ms
Scaling Requires NFS or sticky sessions Centralized, clusterable
Read locks Yes No (by default)
Cluster support Complex Out of the box (Sentinel, Cluster)
Memory consumption Disk + OS cache RAM (configurable maxmemory)

How to configure Redis for Bitrix sessions

Installation and basic configuration

Install Redis and the PHP extension:

apt install redis-server php-redis # Ubuntu/Debian yum install redis php-pecl-redis # CentOS/RHEL 

Basic configuration /etc/redis/redis.conf for sessions:

bind 127.0.0.1 port 6379 maxmemory 256mb maxmemory-policy allkeys-lru save "" # disable persistence for sessions 

Connect PHP sessions to Redis:

session.save_handler = redis session.save_path = "tcp://127.0.0.1:6379?weight=1&timeout=2&prefix=SESS_&database=1" 

For Bitrix, sessions are managed through /bitrix/php_interface/dbconn.php or bitrix/.settings.php. The best approach is to set parameters via the web server configuration for a specific virtual host, rather than globally in php.ini.

Configuration via Bitrix .settings.php

Bitrix supports custom session handlers through 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

$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 — it shows operations in real time. Under normal operation, you will see GET SESS_<id> on each request and SET SESS_<id> when the session is modified.

Important nuance: Bitrix sessions

Bitrix stores authentication, cart (for unauthenticated users), and CSRF tokens in the session. session_write_close() is called at the end of the request. If the handler has locks, under high concurrency for the same user, requests queue up. In most cases this is fine, but for AJAX-heavy pages, you should call session_write_close() immediately after reading session data if no further writes are needed.

How to measure performance gain after Redis?

Use AB testing: before and after setup, measure response time for an authenticated page. Example command:

ab -n 1000 -c 10 https://example.com/ 

Compare the average request time. Also monitor the number of locked sessions at peak — it should approach zero.

Our work process

  1. Analysis: assess current load, architecture, configurations.
  2. Design: choose topology (standalone, sentinel, cluster), calculate memory.
  3. Implementation: install Redis, configure PHP and Bitrix, migrate sessions.
  4. Testing: load testing, failover verification.
  5. Deployment: move to production, set up monitoring (Redis Dashboard, Grafana).

What's included in the work

  • Preparation of a server or container (Docker/Ansible).
  • Installation and configuration of Redis tailored to your load.
  • Integration with Bitrix via .settings.php.
  • Setup of replication and automatic failover (optional).
  • Documentation (schema, parameters, recommendations).
  • Team training (1 hour).
  • 30-day warranty for correct operation.

About our experience

We are a team of certified Bitrix specialists with 7+ years of experience. We have completed over 50 optimization and scaling projects, including Redis session setup for sites with 50,000+ unique visitors per day. We work with both cloud solutions (Bitrix24) and on-premise editions.

Contact us for an assessment of your project. Typical Redis configuration costs start at $500, and server cost savings often exceed $2000 per month. Order a turnkey Redis configuration — get a free architecture consultation and a risk-free test run.

For a project with 100,000 unique visitors per day, use Sentinel with three nodes: Master (maxmemory 1GB, save ""), Slave (replica-read-only yes), Sentinel (monitor mymaster 127.0.0.1 6379 2). More details: official Sentinel documentation.

Useful links: external resource, Wikipedia page