Performance Profiling for 1C-Bitrix Websites

Why a Bitrix site slows down as load grows

A Bitrix site rarely "slows down in general" — usually degradation shows up in specific scenarios: a catalog with filters, the cart, the personal account area, and 1C export.

Up to a certain threshold everything works, but after traffic or data volume grows, response time increases non-linearly.

The reason is that performance bottlenecks accumulate in layers: heavy database queries without indexes, unoptimized components that pull related entities on every page, improperly configured caching, and synchronous external integrations that block rendering.

A telling example is slow queries that are invisible in the interface.

A catalog component with a smart filter, as the number of products grows, starts building a selection across several tables without a covering index, and every page view turns into dozens of heavy database calls.

On the surface it looks like "the site has become slow," and trying to fix it by editing the template is pointless — the root cause is in the query structure and the data schema.

The second common layer is caching. The cache may be formally enabled but gets reset on every request due to sloppy invalidation or dynamic blocks that bypass it.

Then the load on the site grows linearly with the number of visitors, even though it should be almost entirely absorbed by the cache.

Integrations stand apart: a synchronous exchange with 1C or an external service holds the page response until the call completes, and a single slow external response slows down an entire section.

Bitrix profiling differs from "optimizing by eye" in that it first measures and only then changes. A real picture is captured: which queries run on a page, how long each one takes, where the cache fails to hit, and which calls go outside.

This makes it possible to find the root cause rather than the symptom — not to speed up a specific page, but to remove the reason an entire class of scenarios slows down. Let's break down how this is built into a repeatable process.

What profiling delivers: measurable effect

Profiling is not about "making the site faster in general," but about getting a precise answer to which code, query, or external call is consuming response time.

Tools such as the built-in 1C-Bitrix profiler and XHProf show a call tree with accumulated time for each function and component, so optimization is driven by facts rather than guesswork.

Without measurements, changes usually miss the mark: they speed up what was already working, while the bottleneck remains.

Response time. The report shows which components, templates, and database queries account for the bulk of page generation time. After eliminating the heavy sections, typical pages return responses noticeably faster, and the cache stops missing on every hit.

Stability under load. A profile taken at peak load, rather than on an empty site, reveals where degradation begins: table locks, suboptimal queries, synchronous calls to external services.

Once these sections are removed, the site handles peak traffic without growth in response time or queues.

Eliminated class of failures. Some outages are not "the server went down," but a specific slow query that, under a combination of conditions, blocks the connection pool. Profiling surfaces such spots, and the failure stops recurring.

Reduced infrastructure load. Fewer unnecessary queries and computations per hit means lower CPU and memory consumption. This defers server expansion and makes system behavior predictable.

The effect is measured before and after: page generation time, share of database queries, resource consumption under load. We record these metrics so that the result is verifiable rather than declarative.

Profiling methods: built-in and external

The built-in performance monitor gives a quick answer to the question "where does it hurt": it breaks down request time by stages — kernel initialization, component execution, database queries, template processing.

It is enabled selectively, on a specific page or in the administrative section, and immediately shows the call tree with accumulated time.

There is one limitation: it only sees code inside the platform and does not explain what happened at the level of the web server, cache, or network.

External profiling is connected when the picture inside the kernel is already clear, but the bottleneck remains.

A server-side profiler shows the full request path — from accepting the connection to returning the response, including the operation of the database, file operations, and external calls.

This reveals losses that the built-in monitor does not see: slow indexes, unnecessary disk access, locks.

Manual stage-by-stage measurement is used selectively — when a specific hypothesis needs to be confirmed: wrap a section of code in a timer, compare execution time before and after the fix.

The method is precise, but does not scale: covering the entire request this way takes longer than connecting a profiler.

In practice, the approaches are combined: the performance monitor localizes the problem area, external profiling explains the cause, and manual measurement confirms the result after optimization.

This order saves time — you do not have to deploy a heavy tool for a task that the built-in one solves.

How we conduct profiling: stages of work

Profiling begins not with edits, but with capturing the initial state: without baseline metrics, it is impossible to prove that changes made any difference.

We measure page generation time, the number and duration of database queries, the size of result sets, and memory consumption on typical scenarios — catalog, product page, cart, personal account.

We take measurements on a copy of the production environment with a real data volume, because bottlenecks do not manifest on an empty database.

1. Capturing baseline metrics. We record the profile before any intervention: response time for key pages, number of queries per page, peak memory, share of time spent in templates and components. This is the reference point for comparison.
2. Analyzing database queries. We look for queries without indexes, result sets with excessive fields, and repeated calls inside loops. We examine each heavy query separately: execution plan, number of rows scanned, and the possibility of caching the result.
3. Examining components and templates. We look at which components execute on every hit, where duplicate data fetching occurs, and which calls can be moved outside the loop or served from cache.
4. Checking the cache. We analyze what is actually cached and what gets invalidated on every update. Often a page is not cached because of a single dynamic block — we find it and isolate it so that the rest is served from cache.
5. Load testing. We run scenarios with concurrent users and observe how the system behaves as load increases: where queues appear, and what hits the limit first.
6. Report and remediation plan. We compile before-and-after measurements, show which changes had an effect and which turned out to be useless, and propose the order for further optimization.

This sequence eliminates guesswork: every change is based on a measurement, and the result is verified by a repeat test.

What the client receives as a result of profiling

Profiling ends not with a "diagnosis," but with a set of artifacts you can work with going forward — hand off to another contractor, return to in six months, or use to verify our work against the facts. Below is exactly what remains in your hands after the work is delivered.

• Bottleneck map. A list of areas tied to specific pages, components, and calls: where time is lost, which queries are executed repeatedly, which handlers fire on every hit. With priorities — what delivers an effect immediately and what requires reworking the logic.
• Report with measurements. "Before" snapshots for key scenarios: page generation time, number and duration of database queries, size of result sets, behavior under load. The same "after" measurements — so the effect is visible in numbers, not in words.
• Recommendations on caching and queries. What to cache and at what level, where invalidation is configured too aggressively, which result sets can be reduced or combined, which indexes to add. With an indication of which changes are safe and which alter the behavior of the logic.
• Optimization plan. A sequence of work with an estimate of labor intensity and impact on speed: first what removes the main load, then the less critical items. The plan can be executed in parts or handed off to your own team.
• Monitoring regulations. Which metrics to collect continuously, at which thresholds alerts fire, what to check before a release and after a platform update. So that degradation is caught at the rollout stage, not through user complaints.
• Diagram of environments and access. Where measurements were taken, how the staging environments differ from production, which data was anonymized. This removes the main risk — "fast on test, not in production."
• Reproduction protocol. The commands and scenarios with which any of your engineers can repeat the measurement and compare the result with the baseline. Without this, the report turns into a document that no one will ever re-verify.

Such a package closes the question of "what next": you have both an understanding of the causes and a step-by-step plan, as well as a way to control the result after implementation. Describe the task — we'll come back with an estimate and a work plan.

Case Study: Speeding Up a Bitrix Online Store

A catalog of 40,000 items generated the list page in 4.8 seconds, and during peak sale hours the time reached 11 seconds — carts grew, conversion dropped.

Measurements showed 620 database queries per catalog page: some due to missing cache on filters, some due to queries without indexes on product properties.

Bitrix in this project was running without composite cache enabled and with unoptimized catalog components. Profiling showed that 70% of the time was spent on repeated queries to infoblocks and on rebuilding the menu on every request, even though the data changed once a day.

What Was Changed

• Enabled composite cache for the catalog and static blocks, moved heavy queries into managed cache with invalidation by infoblock events.
• Rewrote the catalog components: removed nested loops over properties, added database indexes for filters and sorting.
• Split the load: moved heavy operations (price recalculation, exports) into background jobs so they wouldn't block page delivery.

Result After Optimization

Catalog page generation time dropped from 4.8 to 0.6 seconds, and the number of database queries — from 620 to 90.

Under peak load (6 times higher than normal), the site maintained response without degradation: previously, under such traffic, pages started returning errors, but now no request queue formed.

The client confirmed the result by their own metrics: the bounce rate on catalog pages decreased, and the number of completed orders during peak hours increased. They separately noted that after moving background tasks out, prices stopped "fluctuating" during sales.

How profiling differs from cache optimization

Cache and profiling solve different problems, and confusing the two is costly. Cache eliminates repeated work: a page is built once, the result is served from storage, and response time drops.

Profiling answers a different question — why a specific query or section of code takes so long to execute. The first hides the symptom, the second finds the cause, and the order of work is always the same: diagnostics first, then cache.

Until the cause is found, cache masks it and creates new problems. A heavy database query continues to execute on every cache reset, and resets happen on every catalog or price update.

As a result, the site runs fast for some visitors and crashes for others — those who hit the rebuild. Profiling shows exactly where time is lost: in which component, on which query, how many times it is called on a single page.

After that, the solution becomes obvious. If the bottleneck is an unindexed query, an index helps, not cache. If the problem is redundant calls to a single component, it is removed or merged.

And only after that does cache lock in an already fast result rather than hide a slow one. This order produces a lasting effect: response time stops depending on whether the cache is warm or not.

Starting with cache means postponing the cause. It will return at the first content change, as the catalog grows, or when moving to a new load.

Profiling finds the source, optimization eliminates it, cache locks in the gain — in this sequence, the work produces a predictable result rather than a temporary speedup.

Common technical concerns about profiling

Profiling runs on a live site: we capture a profile from real traffic or from a separate environment where the production config and a copy of the database have been replicated.

There is no need to stop production — metrics collection runs in parallel with serving requests, and we move heavy measurements into a low-load window so as not to add response time for live users.

The profile data shows which calls consume time: database queries without indexes, repeated cache hits, heavy components on catalog pages. This then turns into a list of fixes with an estimate of the effect — what will deliver acceleration and what merely shifts the load.

Is one measurement enough to find the bottleneck?

One measurement shows the picture at a specific moment. Bottlenecks show up under load and across different scenarios — catalog, cart, account area, search.

That is why we take a series of measurements across key pages and compare: this way it is clear what is consistently slow and what depends on peaks.

Is this safe for data and access?

Yes. The profile contains function names and call times, not the contents of orders or personal data. We work within the agreed access scope, and if necessary — on a copy of the database rather than the production one. Access is granted on a targeted basis and revoked once the work is complete.

Will profiling affect site speed for customers?

Metrics collection adds minimal load. We schedule heavy measurements for low-traffic hours, and we enable tools on a targeted basis and disable them immediately after data capture. Users do not notice any difference.

What will we get as a result?

A report with bottlenecks, fix priorities, and the expected effect for each. Then — a work plan: what to fix first, what will deliver acceleration, and what can be postponed without losing the result.

Let's discuss the task and come back with a profiling plan

To come back with a profiling plan rather than generalities, we need a snapshot of your current performance: where exactly it slows down, under what load, and what you've already tried.

Describe the task in free form — based on these inputs, our engineers will put together a scope of work and a sequence of actions for your project.

What's useful to include in the description:

• Which pages or scenarios are slow: catalog, cart, checkout, personal account, admin panel, 1C integration.
• How the problem manifests: server response time, slow rendering, timeouts, failures under load, user complaints.
• Load profile: how many concurrent visitors, peak hours, seasonal spikes, promotions and sales.
• What's already been done: enabled caching, composite mode, server settings, attempts to optimize on your own or by a previous contractor.
• Infrastructure: where the project is hosted, how the 1C integration is set up, whether there are separate servers for the database and the application.
• Constraints: windows when production can't be touched, availability requirements, roles and permissions on the servers.
• Benchmarks: what page response time you consider acceptable and by which metrics you'll judge the result.

Based on this data, we'll determine where to look for the bottleneck — in component code, in database queries, in server configuration, or in the 1C integration — and propose a sequence of work: where we start, what we check at each step, how we record the result before and after.

The estimate and plan will come to you as a working document you can make a decision from, not as a verbal sales pitch.

Describe the task — we'll come back with an estimate and a profiling plan.