Load Testing for 1C-Bitrix E-commerce Sites
A typical situation: the store runs stable with 30 concurrent visitors, but at 300, catalog pages take 8 seconds to load, checkout fails with a timeout, and nginx logs show 502 Bad Gateway. The owner finds out on the first day of a sale. The potential savings from timely testing can reach up to 5 million rubles. According to industry research, a 100ms delay reduces conversions by 7% —Akamai Research. We help identify bottlenecks before they become critical. Our load testing service typically ranges from $1,000 to $5,000 depending on complexity.
Why Performance Validation Is Essential Before Sales
Without stress testing, you risk losing up to 70% of revenue on the day of a promotion. Traffic can exceed current capacity by 10–20 times, and without a scaling plan, the store will go down. Load testing provides answers: how many requests per second the current configuration can handle, where the bottleneck lies (DB, PHP-FPM, external APIs), and what safety margin to allocate. Timely detection of bottlenecks prevents revenue loss that can amount to millions of rubles. For a store with $1M monthly revenue, an hour of downtime during a sale could cost $20,000.
Load Generation Tools
k6 is our first choice for most projects. JavaScript scenarios, minimal resource consumption (a single machine can output 5,000+ RPS), native Grafana integration for real-time visualization. It lives in the repository and runs in CI/CD. k6 is 10 times more memory-efficient than JMeter for the same number of virtual users. Composite caching can speed up page delivery by 100x compared to dynamic generation. Example scenario for a Bitrix catalog:
Example k6 script
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '2m', target: 100 }, // ramp-up
{ duration: '5m', target: 100 }, // plateau
{ duration: '2m', target: 300 }, // stress
{ duration: '5m', target: 300 }, // hold
{ duration: '2m', target: 0 }, // ramp-down
],
};
export default function () {
// Home → section → filtering → product card
let res = http.get('http://localhost/catalog/electronics/');
check(res, { 'catalog 200': (r) => r.status === 200 });
res = http.get('http://localhost/catalog/electronics/?filter_brand=samsung&filter_price_from=10000');
check(res, { 'filter 200': (r) => r.status === 200 });
res = http.get('http://localhost/catalog/electronics/samsung-galaxy-s24/');
check(res, { 'product 200': (r) => r.status === 200 });
sleep(Math.random() * 3 + 1); // pause 1-4 sec, simulate real user
}
Apache JMeter is a proven standard; it requires Java and consumes more RAM, so for high loads, multiple instances may be needed. GUI for scenario creation, proxy recording, supports cookies and authorization. Suits teams accustomed to visual tools.
Gatling uses Scala DSL, non-blocking I/O, detailed HTML reports with percentiles. More resource-efficient than JMeter, but with a steeper learning curve.
| Tool | Language | RAM for 1000 VU | Reports | CI/CD |
|---|---|---|---|---|
| k6 | JavaScript | ~200 MB | Grafana / JSON | Native |
| JMeter | GUI / XML | ~2 GB | Plugins (JTL) | Via CLI |
| Gatling | Scala DSL | ~500 MB | HTML built-in | Native |
Four Scenarios to Test
A load test without realistic scenarios is just meaningless traffic generation on the homepage. For a Bitrix store, the critical ones are:
- Catalog Browsing (60-70% of traffic): home → section → filtering → product card. Filtering is the heaviest part. The bitrix:catalog.smart.filter component generates 30-50 SQL queries per hit.
- Search (10-15% of traffic): the search module uses FULLTEXT indexes, which degrade non-linearly on 100,000+ products.
- Cart (5-10% of traffic): every action (adding, coupon) triggers discount recalculation via RuntimeCache, taking 200-500 ms.
- Checkout (2-5% of traffic): the most critical scenario — 50-100 SQL queries and 1-3 HTTP requests to external services.
How to Identify Bitrix Bottlenecks
Load testing shows what is slow. Profiling explains why. We provide flame graphs from xhprof to pinpoint hot functions.
Xhprof / Tideways are PHP profiling extensions with 5-15% overhead. Enable them on production under load to generate a call graph. A typical finding: CIBlockElement::GetList() called 47 times on a single catalog page.
Slow query log is mandatory during the test. For MySQL: slow_query_log = 1, long_query_time = 0.3. A typical finding — a filter query with five JOINs on property tables scanning 2.3 million rows in 4.2 seconds.
Common Bitrix Bottlenecks
- Components without cache:
bitrix:catalog.sectionwithCACHE_TIME = 0— each hit generates info block and price queries. Solution — tagged cache (CACHE_TIME = 3600). - Multiple info block properties: each property is stored as a separate row, filtering on three properties adds three extra JOINs. Faceted index solves this.
- No OPcache: without it, Bitrix compiles thousands of PHP files on every request. Set
opcache.memory_consumption = 256,max_accelerated_files = 20000. With OPcache, PHP execution is 3-5 times faster. - File-based sessions: with 500+ concurrent users, ext4 slows down. Use Redis:
session.save_handler = redis. Using Redis instead of file-based sessions improves session handling performance by 5x. - Agents on hits: define
BX_CRONTAB_SUPPORT = trueand move agents to cron.
Key Metrics
- RPS — requests per second without degradation (for an average store: 100-300).
- TTFB — up to 200 ms for cached pages, up to 500 ms for dynamic ones.
- P95 response time — time for 95% of requests. If P95 > 4 seconds, one in twenty visitors waits too long.
- Error rate — percentage of 5xx and timeouts. It rises sharply when capacity is exceeded.
What to Do with the Results
| Problem | Metric | Solution |
|---|---|---|
| TTFB > 1 s on catalog | P95 | Component cache + composite cache |
| 502 at 200+ RPS | Error rate | Increase pm.max_children, tune max_connections |
| Slow query > 2 s | Slow query log | Faceted index, composite indexes, Elasticsearch |
| OOM at 300 users | Memory usage | OPcache, memory_limit, disable modules |
| Checkout timeout | TTFB | Async event processing, delivery cache |
When to Test
Load testing is not a one-time task. Run it before sales (Black Friday, 11.11), after server migration, after updating the Bitrix kernel, after mass product imports. k6 in CI/CD allows a basic smoke test on every deploy.
How to Conduct Load Testing in 5 Steps
- Gather load profile: typical scenarios, request frequency, peak traffic.
- Set up environment: staging with monitoring and profiling enabled.
- Develop scenarios: k6 scripts simulating catalog, search, checkout.
- Execute and monitor: gradually ramp up load, record RPS, TTFB, P95, error rate.
- Analyze and optimize: examine slow query log, profiler, implement changes, retest.
What's Included in Our Work
We provide a full-cycle load testing service backed by over 10 years of experience and 1C-Bitrix certification. We guarantee a comprehensive report with actionable recommendations:
- Analysis of your store's architecture and load profile.
- Development of realistic scenarios (catalog, search, cart, checkout).
- Execution of tests on staging or production (with your approval).
- Metrics collection and profiling (xhprof, slow query, OPcache).
- Detailed report with metrics, bottlenecks, and recommendations.
- Priority optimization plan with effort estimates.
- Engineer consultation on results.
Contact us for a consultation — we will assess your project in 1-2 days. Order testing before sales to avoid revenue loss.