Consulting on scaling the 1C-Bitrix project

1C-Bitrix Project Scaling Consultation

A site starts failing under load — 500 concurrent users, a flash sale, Black Friday. A single server hits CPU or I/O limits. Horizontal scaling of Bitrix is possible, but requires specific solutions: sessions must not be pinned to a particular machine, the cache must be shared, and uploaded files must be accessible from all nodes.

Bitrix Cluster Architecture

Bitrix supports cluster configuration in the Business edition and above ("Scaling"). Components of a typical cluster setup:

[Load balancer: nginx / HAProxy]
         |
    +---------+
    |         |
[Web-1]   [Web-2]   ... [Web-N]  — PHP-FPM
    |         |
    +---------+
         |
[Shared storage: GlusterFS / NFS / S3] — /upload/, /bitrix/cache/
         |
[Redis cluster] — sessions, managed cache
         |
[MySQL / PostgreSQL Master] → [Slave-1] [Slave-2]

Sessions and Cache

Sessions. Standard PHP stores sessions in files on the local disk — with multiple servers, a user loses their authenticated session when routed to a different node. Solution: move sessions to Redis.

In /bitrix/.settings.php:

'session' => [
    'value' => [
        'mode' => 'default',
        'handlers' => [
            'general' => [
                'type' => 'redis',
                'host' => '127.0.0.1',
                'port' => '6379',
            ],
        ],
    ],
],

Bitrix ManagedCache is also moved to Redis:

'cache' => [
    'value' => [
        'type' => 'redis',
        'redis' => ['host' => 'redis-host', 'port' => 6379],
    ],
],

Shared File Storage

The /upload/ and /bitrix/cache/ directories (disk cache) must be shared across all web nodes. Options:

For Bitrix: the disk module and uploads (/upload/) are mounted on shared storage. It is better to move the cache to Redis and disable disk cache entirely.

Database Replication

Bitrix supports working with multiple database hosts via DBConnectionPool in /bitrix/.settings.php. Writes go to Master, reads to Slave. Configuration:

'connections' => [
    'value' => [
        'default' => [
            'host' => 'db-master',
            ...
        ],
        'slave' => [
            'host' => 'db-slave-1',
            ...
        ],
    ],
],

Custom code must explicitly specify the read connection via Application::getConnection('slave').

Scaling Bottlenecks

Agents. Standard Bitrix agents are triggered in the web request flow on every page hit. In a cluster, this means concurrent execution of the same agent on multiple nodes. Solution: move agents to a dedicated cron process on a single server, disabling web-based execution via BX_CRONTAB.

PDF generation and heavy tasks. Document generation, reports, and batch operations must not run in the web request flow. A task queue is needed — RabbitMQ or Redis Queue — with workers on dedicated servers.

Core updates in a cluster. Rolling update without downtime: update nodes one at a time, provided the update is backward-compatible with the current database schema.

Load Testing

Before scaling — load test on a staging environment identical to production. Tools: Apache JMeter, k6, Yandex.Tank. Test scenarios:

• Catalog page with active filters
• Order placement (database transactions)
• AJAX requests (cart, filter)

Result: a performance degradation curve as load increases, with the bottleneck identified — CPU, RAM, I/O, or database.

What Is Included in the Scaling Consultation

• Analysis of current bottlenecks under load (profiling, monitoring)
• Design of the target cluster architecture
• Recommendations for Redis, load balancer, and database replication configuration
• Setup of shared file storage
• Migration of Bitrix sessions and cache to Redis
• Offloading agents and heavy tasks from the web request flow
• Load testing methodology and result evaluation