Bitrix Load Testing: Preparation, Tools, Case Studies

Load testing Bitrix: where the site breaks

Load testing Bitrix begins not with launching a traffic generator, but with answering the question: which exact scenario are we breaking. For an online store on "Bitrix", bottlenecks almost always lie in four places — cache, search, cart, and exchange with 1C.

While the site runs on ten concurrent visitors, all four look healthy. At peak load — a sale, the start of a promotion, evening traffic — they manifest simultaneously and reinforce each other.

Cache degrades first.

Components with CACHE_TYPE => A and an aggressive lifetime serve stale prices and stock, and when the cache is reset by an event (product change, import from 1C), hundreds of requests simultaneously hit the database — connection timeout, a white screen instead of the catalog.

Forced caching in files on a shared disk subsystem adds read-write locks, and response time grows non-linearly: when visitors double, the response can triple.

Search is the second bottleneck. The built-in index-based search on large catalogs performs heavy queries, and morphology and suggestions add requests on every keystroke. At peak load, search queries consume database connections, and the product page no longer gets its turn.

The cart and checkout hold the session and transactions. When products are added to the cart en masse, locks on order tables grow, and integration with 1C via scheduled exchange launches heavy exports at the very moment when the sales peak is underway.

The exchange and the storefront begin competing for the same resources — orders are lost, statuses are not synchronized.

That is exactly why we build Bitrix load testing as a search for bottlenecks, not as a report on "withstood N requests per second".

First we capture a profile of real traffic, then reproduce the peak scenario and see what degrades first — cache, search, cart, or exchange. Next we work out how it gets resolved.

What testing delivers: measurable results

Load testing of Bitrix moves the conversation about performance from the realm of impressions into the realm of numbers.

Before the runs, the team has complaints ("it slows down at lunchtime," "the cart falls over during a sale"); after, there's a load profile: how many requests per second the catalog sustains, at what concurrency response time starts to climb, and exactly where the worker hits its ceiling. From there, decisions are made based on these figures, not on intuition.

Throughput and response time are measured separately because they behave differently. A system can steadily accept a stream of requests while still serving the catalog page in seconds — for a visitor that's a failure, even though the request counter looks healthy.

A run reveals the inflection point: up to it, response stays within the target corridor; beyond it, it grows nonlinearly. That boundary is what gets protected with caching, indexes, and offloading heavy operations.

Fault tolerance is tested separately from peak load. A scenario removes one node from the group — database, search, queue — and observes whether the system degrades gracefully or collapses entirely.

It often turns out that fault tolerance is declared in the configuration but never verified: failover doesn't work, sessions are lost, background jobs get duplicated. Such runs are cheaper than an incident on the production environment.

A separate effect is release predictability. When there's a reference load profile, every change is run against it, and response-time regression is visible before deployment to prod. The team gets not a one-off report but a measurable bar below which a release doesn't pass.

Approaches to load runs: comparison

A load run can be organized in four fundamentally different ways, and the choice between them is determined not by budget, but by which bottlenecks you want to see.

A manual run by a team with several browsers gives quick feedback on interface responsiveness, but does not reproduce the profile of real sessions: authorized users, cart, exchange with 1C.

A scripted run on Bitrix via the built-in mechanism or an external generator gives repeatability and metrics, but requires a correct scenario — otherwise you are measuring not the production load, but the operation of the test script.

Each approach has its own limitations, and it is important to discuss them before the start. A test on a copy will not show degradation from real traffic if the copy lags behind in data and cache configuration.

Distributed load gives an honest picture only with a single point of metric collection — otherwise the bottleneck will be "lost" between the generators. A manual run does not replace a scripted one, but complements it: it catches what is not built into the scenario.

How the project works: stages of work

Work proceeds in iterations: first we record the current state and goals, then we reproduce the load, and only after that do we change the configuration.

This order eliminates "blind optimization," where edits are made based on intuition and produce no measurable effect.

1. Configuration audit. We take a map of the environment: web server and PHP parameters, caching settings, indexes and slow queries in the database, the composition of components and modules, external integrations. The output is a list of bottlenecks with an assessment of which one will limit the system first.
2. Gathering load requirements. We clarify the user profile: which pages they open, how they log in, what they put in the cart, how often they access personal sections. From this grow the target metrics — how many concurrent sessions and what response time we consider acceptable.
3. Preparing load scenarios. We describe real journeys, not individual requests: login, catalog, checkout, personal account. We parameterize the scenarios — different users, different products, different "thinking" times, otherwise the test shows an ideal picture that never occurs in real life.
4. Test environment and data. We deploy a copy of the production configuration and fill it with a volume of data comparable to production. Testing on an empty database is pointless: queries fly, but they degrade on real volumes.
5. Run and profiling. We apply load in steps, recording exactly where the growth in response time and errors begins. In parallel, we capture server, database, and application metrics — this allows us to distinguish a lack of resources from inefficient code.
6. Optimization and re-run. We eliminate what was found: cache, indexes, heavy queries, connection settings. After each edit, we repeat the same scenario — a "before/after" comparison shows the real gain, not the expected one.
7. Handing over the results. We deliver a report with graphs and bottlenecks, a test launch procedure, and monitoring recommendations so the team can repeat the check before major releases and sales.

The key principle is verifying results at every step, not only at the end. Describe your task: load profile, peak periods, current symptoms — we will get back to you with an estimate and a plan of stages.

Deliverables: what the client keeps

At the end of load testing, the client receives not a presentation with charts, but a working kit that the operations team can use to repeat the runs on their own — without us and without verbal explanations.

Everything is stored in a repository alongside the project, versioned, and updated whenever the architecture changes.

• Load scenarios — user behavior profiles: authentication, catalog, checkout, admin operations. Each scenario comes with a target number of concurrent sessions, role distribution, and measurement points.
• Stand and generator configurations — parameters of the environment where the results were captured: service composition, caching settings, connection limits. Without them, the report figures are not reproducible.
• Load testing report — response time and throughput charts by scenario step, share of errors and timeouts, bottlenecks tied to specific components, and an estimate of headroom before degradation.
• Run regulations — when and what to launch: before a release, after a configuration change, when traffic grows. With pass/fail criteria and thresholds beyond which a release is blocked.
• Remediation recommendations — a prioritized list: what to change in the code, what in the server settings, what in the caching scheme. With the expected effect for each item.
• Scripts and tooling — the scenario files themselves and auxiliary launch scripts, so a run can be repeated with a single command.
• Documentation — a brief description of the stand, a request flow diagram, and instructions for the engineer opening the kit for the first time.

We hand over the kit with a walkthrough: we show how to read the report, where to change the load profile for a new seasonal peak, and how to distinguish degradation from a one-off spike.

After that, you either run the tests yourselves or come back to us for the next cycle — in either case, the baseline and measurement history stay with you.

Case: eliminating failures under peak loads

What it was before

The project — an online store on 1C-Bitrix with a catalog of several tens of thousands of items and scheduled exchange with 1С.

In normal mode, the site responded in 300–500 ms, but during sales and catalog synchronization, failures began: the share of 5xx errors reached 12%, some orders did not go through, and the cart lost items when the form was resubmitted.

Monitoring recorded a growing queue for request processing and hitting the connection limit with the database.

What was changed

First, a profile was taken under a load replicating real peaks: simultaneous login, catalog search, adding to cart, and checkout. The test reproduced a 5x increase over the daily average and holding the peak for 20 minutes — exactly how long a sale wave lasts.

Based on the results, the bottlenecks were reworked: the catalog and price cache was moved to a separate layer so that the exchange with 1С would not reset it entirely, database reads and writes were separated, indexes were added for heavy filters, and parallel exchange tasks were limited. Order checkout was switched to idempotent processing — resubmission no longer creates duplicates.

What it became

The site now goes through peak waves without manual intervention, and the exchange with 1С runs in parallel with traffic and does not bring down the storefront.

The test remained in regression — before each release we run the same scenario and compare metrics against the baseline, so that degradation is caught before deployment, not on the day of the sale.

How does load testing differ from stress testing?

Load testing checks how a system behaves under design load — the load specified in the requirements and confirmed by the profile of real traffic.

We reproduce a typical scenario: the share of authenticated users, the read-to-write ratio, activity peaks during business hours, and the behavior of the cart and checkout.

The goal is to make sure that under normal traffic, response time stays within acceptable limits and the servers do not become overloaded. The result is confirmation that the system will withstand the expected traffic, plus resource headroom for growth.

A stress test solves the opposite problem: we deliberately raise the load above the design level and look for the failure point — the moment when response time exceeds acceptable limits, the request queue grows, or a specific node fails.

What matters here is not a pretty graph, but understanding what breaks first: the database, the cache, the web layer, or an external integration. This shows where the resilience boundary lies and how the system degrades — smoothly or abruptly.

The difference is in the approach to the result.

Load testing answers the question "can we handle what is expected," while a stress test answers "what happens if we exceed what is expected many times over." The first confirms readiness for launch and planned growth; the second confirms resilience to anomalies: a sale, viral traffic, or the failure of an adjacent service.

Both scenarios are built on the same tooling and user profile, but their goals and acceptance criteria are different.

In practice, we run them sequentially. First, the load profile confirms that the design load is handled normally, then we step up the traffic until failure and record the threshold.

This way the customer gets not an abstract "the site is fast," but specifics: at what number of concurrent users the system holds up, where degradation begins, and which nodes require headroom.

Common technical concerns

Load testing of Bitrix almost always comes down to three engineering questions: whether a run will bring down the production site, where to get the data, and how often to repeat it. Below are the answers that a technical client most often needs before starting.

How should data be prepared so the results are honest?

An empty database lies: queries fly, the cache warms up instantly, and bottlenecks don't show up. You need a volume comparable to production — in terms of the number of products, sections, users, and orders, with the same structure of information blocks and properties.

Separately, we warm up the cache before measuring, otherwise the first run will show not performance but cold start time.

How often should runs be repeated?

A one-time check answers only the current question. After that, it makes sense to tie a run to changes: a major release, a server configuration change, catalog growth, a seasonal sale.

Then the comparison is against the previous measurement, and degradation is visible immediately, not on the day of peak load.

What if the bottleneck is not the server?

Often the bottleneck turns out to be the database, an external API, or a slow component query, rather than the hardware. That's why the report includes not only graphs but also a profile of heavy queries and the most expensive pages — they show what to optimize first.

Describe your environment and peak scenario — we'll come back with a run plan, data preparation, and an estimate.

Let's discuss your load testing task

To come back with an estimate and a plan, rather than generalities, we need to understand the load profile and the boundaries of the system.

Tell us what is already known: what peak traffic you expect, which scenarios are critical (checkout, logging into the personal account, exchange with 1C, catalog export), whether there are seasonal spikes, and how prod currently behaves under load. This is enough to propose a test scheme and estimate the scope of work.

Next, we clarify the technical setup — both the methodology and the timelines depend on it:

• current configuration: web servers, database, cache, load balancer, dedicated services;
• how the exchange with 1C and external systems is organized — on a schedule or in real time;
• where to deploy the test environment: is there a site comparable to prod in terms of resources;
• what data can be used — an anonymized copy of the database or synthetic data;
• access and windows during which it is acceptable to load the system without risk to production users;
• target metrics: response time of key pages, acceptable error rate, degradation threshold.

Based on the conversation, we fix the scenarios, acceptance metrics, and stages: preparing the environment, taking a baseline, a series of load runs with increasing intensity, analyzing bottlenecks, and a report with optimization recommendations.

You get not just numbers, but a list of specific growth points — what to change in the configuration, caching, and queries so that the system can handle the peak.

Describe the task in any convenient format — we will come back with a load testing estimate and a work plan. If needed, an engineer will join the discussion and help formulate scenarios even before the start.