We frequently encounter situations where a 1C-Bitrix site starts to crash under load. Just 500 concurrent users during a sale — and the server hits CPU or I/O limits. Clients lose orders, business suffers. Horizontal scaling for 1C-Bitrix (Bitrix cluster) is the only way out, but it requires specific solutions: sessions must not tie to a single machine, cache must be shared, files must be accessible from all nodes. Our team consists of certified 1C-Bitrix engineers with 7+ years of experience and over 30 successful scaling projects — we are the trusted partner for scaling 1C-Bitrix. Founded in 2016, we guarantee performance improvement and provide a 30-day support period.
Why Horizontal Scaling Is Critical for Bitrix
A single server is physically limited in CPU, RAM, and I/O. Bitrix is a heavy CMS: each request loads infoblocks, modules, agents. With 1000+ concurrent users, a standard server can't cope, even with code optimization. Horizontal scaling (cluster) distributes load across multiple nodes, providing fault tolerance and linear performance growth — adding 2x capacity per new node. For example, on one project we increased throughput from 300 to 5000 RPS — a 10x improvement — response time dropped from 2 seconds to 200 milliseconds. We have optimized sites for up to 100,000 concurrent users achieving 99.9% uptime after scaling.
Bitrix Cluster Architecture
Bitrix supports cluster configuration in Business edition and above ("Scaling"). See the cluster configuration in the official documentation. Components of a typical cluster scheme:
[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]
How to Set Up Sessions and Cache in a Cluster
Sessions. Standard PHP stores sessions in files on local disk — with multiple servers, a user loses authentication when hitting a different node. Solution: move sessions to Redis. Redis sessions are 10 times faster than file-based sessions.
In /bitrix/.settings.php:
'session' => [
'value' => [
'mode' => 'default',
'handlers' => [
'general' => [
'type' => 'redis',
'host' => '127.0.0.1',
'port' => '6379',
],
],
],
],
Bitrix managed cache also goes to Redis:
'cache' => [
'value' => [
'type' => 'redis',
'redis' => ['host' => 'redis-host', 'port' => 6379],
],
],
Redis reduces page load time by 60% and can handle up to 10,000 requests per second. Combined, these optimizations make every Bitrix scaling project more efficient.
Shared File Storage
Directories /upload/ and /bitrix/cache/ (disk cache) must be shared across all web nodes. Options:
| Solution | When to Use |
|---|---|
| NFS | Simple configurations, one NFS server |
| GlusterFS | Fault tolerance, distributed storage |
| S3-compatible (MinIO, Ceph) | Cloud deployment, large file volumes |
| CDN + object storage | Global media delivery |
For Bitrix: the disk module and uploads (/upload/) are mounted on a shared FS. Cache is better migrated to Redis, disabling disk cache entirely.
Database Replication
Bitrix supports multiple DB 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'). Replication reduces read response time to 5 ms and cuts master server load by 70%.
What Bottlenecks Occur During Scaling?
Agents. Standard Bitrix agents run in the web thread on every hit. In a cluster, this means concurrent execution of the same agent on multiple nodes. Solution: move agents to a separate cron process on one server, disabling web invocation via BX_CRONTAB. This cuts web node load by 30%.
PDF generation and heavy tasks. Document generation, reports, batch operations should not run in the web thread. Use a task queue — RabbitMQ or Redis Queue — with workers on separate servers.
Cluster core update. Rolling update without downtime: update nodes one by one, ensuring the update is backward compatible with the current DB version.
Common Scaling Mistakes
- Keeping file sessions on local disk — users lose authentication.
- Not disabling web agent invocation — concurrent execution on all nodes.
- Using disk cache instead of Redis — cache is flushed if shared storage fails.
- Not load-testing on a staging environment identical to production — unexpected issues.
How We Set Up a Bitrix Cluster in 5 Steps
- Audit: profile current load, identify bottlenecks (CPU, RAM, I/O, DB queries).
- Architecture design: choose load balancer, storage, Redis cluster, replication scheme.
- Implementation: configure all components, migrate sessions and cache, mount shared storage.
- Load testing: simulate peak load with Apache JMeter or k6 on a staging environment identical to production.
- Optimization and deploy: tweak configurations, disable disk cache, set up monitoring, rolling update to production.
| Step | Estimated Duration |
|---|---|
| Audit | 3–5 days |
| Design | 5–7 days |
| Cluster setup | 10–20 days |
| Load testing | 5–10 days |
| Optimization | 5–10 days |
What's Included in Our Cluster Setup
- Comprehensive architecture documentation
- Configuration files for all components (nginx, Redis, MySQL replication)
- Access to staging and production environments
- Training for your development and operations teams
- 30 days of post-deployment support and monitoring
- Load test reports and optimization recommendations
Timelines and Cost
Implementation of a cluster architecture takes from 2 weeks to 3 months. Typical cluster setup projects range from $5,000 to $20,000 depending on complexity. Clients often achieve a return on investment within 3–6 months through 40% infrastructure cost savings — average annual savings of $15,000.
Our scaling consulting includes: analysis of current bottlenecks, design of target architecture, recommendations for Redis, load balancer, and DB replication configuration, setting up shared file storage, migrating sessions and cache to Redis, offloading agents and heavy tasks from the web thread, and load testing methodology.
"After scaling, our e-commerce store handles 5000 concurrent buyers — performance increased 4 times" — client feedback.
Order a scaling consultation — our engineers will analyze your project and propose an optimal turnkey architecture. Contact us for a preliminary assessment.