Load Testing for 1C-Bitrix Site
Load testing answers the specific question: how many simultaneous users will the site handle, at what traffic will errors start, and where exactly will everything break. Without this data, launching an ad campaign or participating in "Black Friday" is a coin toss.
What we test
Load testing a Bitrix site includes several scenarios:
Load Test — gradual increase in load from zero to expected peak. Goal: find the performance degradation point.
Stress Test — load above expected maximum. Goal: find the failure point and check how the system recovers.
Spike Test — sudden load surge (imitating a viral post or mailing). Goal: check behavior under sudden growth.
Soak Test — extended load (several hours) at working level. Goal: find memory leaks, cumulative problems.
Tools
Apache JMeter — multifunctional, with GUI, supports scenarios with authorization, cart, AJAX. Suitable for Bitrix where sessions and dynamic pages are critical.
k6 — modern tool, scenarios in JavaScript, convenient for DevOps:
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 50 }, // ramp up to 50 users
{ duration: '5m', target: 50 }, // hold 5 minutes
{ duration: '2m', target: 200 }, // peak to 200
{ duration: '5m', target: 200 }, // hold peak
{ duration: '2m', target: 0 }, // ramp down
],
thresholds: {
http_req_duration: ['p(95)<2000'], // 95% requests < 2 s
http_req_failed: ['rate<0.01'], // less than 1% errors
},
};
export default function() {
const res = http.get('https://yourshop.ru/catalog/');
check(res, { 'status 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 1); // pause 1–4 s between requests
}
Yandex.Tank — Russian analogue, integrates well with Yandex.Monitoring.
Scenarios for Bitrix store
A realistic scenario doesn't only load the main page, but a typical user path:
40% — catalog page views (GET /catalog/category/)
20% — search (GET /search/?q=product)
15% — product cards (GET /catalog/product-slug/)
10% — add to cart (POST /cart/add/)
8% — authorization and personal account
7% — checkout
Adding to cart via /bitrix/tools/sale_basket.php is an AJAX request with CSRF token check. JMeter or k6 should support extracting CSRF from the page and passing it in POST.
Server monitoring during test
Load testing without server monitoring is half the job. Monitor simultaneously with the load:
PHP-FPM: pm.status_path = /fpm-status — shows active/waiting workers. If active processes = max_children — PHP-FPM saturated, requests queue up.
MySQL: SHOW PROCESSLIST and SHOW STATUS — connection count, locks, slow queries in real time.
Bitrix: performance panel under load shows what generates long requests.
System metrics: CPU, RAM, disk I/O, network. Tools: htop, iostat -x 1, vmstat 1.
For automatic metric collection — Prometheus + node_exporter + Grafana. In 2–4 hours of setup you give the team a dashboard with real data.
Typical Bitrix bottlenecks under load
PHP-FPM exhausts workers. At pm = dynamic and pm.max_children = 20 — 20 simultaneous PHP requests. Others wait. Solution: increase max_children (accounting for RAM — each Bitrix worker takes 50–150 MB) or optimize PHP response time.
MySQL: too many connections. Each PHP worker holds a MySQL connection. 100 workers × 3 sites = 300 connections. At max_connections = 151 (default) — Too many connections errors. ProxySQL or PgBouncer help multiplex connections.
File cache under load. At 200 simultaneous users, hundreds of threads simultaneously read and write cache files. Locks, inode exhaustion on cheap hosting. Redis as cache backend eliminates this problem.
Sessions. If sessions are in files — same problem. Redis sessions under load work more stably.
Test preparation
-
Test environment — load staging if possible, identical to production in server configuration. Testing production without team coordination — high risk.
-
Cache warming — run a crawler over the site before the test so caches are filled. Testing with cold caches shows worst case, not working mode.
-
Baseline metrics — record performance before optimization. Load test before and after — only way to prove effect of changes.
-
URL list — take real URLs from Yandex.Metrica or Google Analytics. Top 50 pages by traffic.
Interpreting results
| Metric | Good | Acceptable | Poor |
|---|---|---|---|
| p95 response time | < 1 s | 1–3 s | > 3 s |
| Errors (5xx) | 0% | < 0.1% | > 1% |
| Server CPU | < 50% | 50–80% | > 80% |
| PHP-FPM active / max | < 60% | 60–85% | > 90% |
Timeline
| Task | Timeline |
|---|---|
| Scenario preparation + tool setup | 1–2 days |
| Basic load test + result analysis | 1 day |
| Server monitoring setup | 1 day |
| Iteration: optimization + retest | 2–3 days |
| Full cycle (4 test types + report) | 1 week |
Load testing makes sense after basic optimization: SQL indexes, caches, OPcache. Testing an unoptimized site — learn what's already obvious.