Configuring Bitrix Performance Panel: Diagnostics and Optimization

When a Bitrix site starts to slow down — clients complain, managers get nervous, and every click in the admin panel takes 10 seconds?

The first tool every developer should master is the built-in performance panel. Over 8 years in the market and 50+ Bitrix projects, we've repeatedly confirmed that its data suffices for 80% of diagnostic tasks without external profilers. Recently, an online store with a catalog of 50,000 items came to us — the catalog page loaded in 12 seconds. After panel tuning and SQL optimization, the time dropped to 1.2 seconds — a 10x improvement, . Such results are typical when you know what to look at. Below we break down how to configure the panel, interpret its metrics, and perform actual optimization.

Enabling the Performance Panel

Activate via the admin interface: Settings → Performance → Performance Panel. For quick debugging, you can enable it programmatically:

// Show panel for the current user $USER->SetShowStatPanel(true); // Or in dbconn.php for debugging on dev environment define('BX_STATPANEL', true); 

The panel is visible only to authorized users in the "Administrators" group. On production, keep it enabled only during active debugging — it adds a small overhead for data collection. According to official Bitrix documentation, the panel does not affect page speed for regular visitors.

Performance Panel Metrics

• Execution time — total PHP + SQL time in milliseconds, broken down into PHP time and MySQL wait time.
• DB queries — number of SQL queries and their total time. Click on the block to open the list of all queries with individual execution times.
• Cache — number of cache accesses: hits and misses. A low hit rate (<80%) signals inefficient cache configuration or too frequent invalidation.
• Files — number of included PHP files. 500+ files without OPcache means slow initialization.
• Memory — peak PHP script memory consumption. 64 MB+ indicates a need to check for leaks or excessive data loading.

For convenience, here are normal values in a table:

Typical problems and their solutions are compiled below.

Detailed SQL Profiling

Click on the SQL block in the panel to open the list of all queries. Sort by time. Queries >50 ms are candidates for optimization via EXPLAIN. Queries that repeat 10+ times with the same pattern indicate an N+1 problem. Usually these are infoblock element properties fetched one by one. Comparison: a properly built query with a single JOIN runs 10-20 times faster than N individual queries.

Configuring the Performance Monitor

In the menu Settings → Performance → Performance Monitor, set:

• Recording threshold — 1000 ms for production, 500 ms for staging
• Records to store — 1000–5000 entries in the b_perf_hit table
• Record SQL — enable to see the query list for slow pages

View the log: Settings → Performance → View Log. Sort by total SQL time — that's where the most problematic pages appear.

Diagnostic Algorithm for a Specific Problem

1. Open the slow page with the panel enabled.
2. Check the ratio of PHP time vs SQL time. If SQL >70%, optimize queries. If PHP time is large with small SQL — the problem lies in component code.
3. Open the SQL query list, sort by time.
4. Copy a slow query, run EXPLAIN in MySQL Workbench or phpMyAdmin. Often adding an index reduces query time by 5-10x.
5. Add the missing index, refresh the page, and confirm improvement.

A typical case: on one project, the catalog page loaded in 8 seconds. The panel showed 250 SQL queries. EXPLAIN revealed missing indexes on the IBLOCK_SECTION_ID field. After adding the index, the page loaded in 0.8 seconds — a 10x improvement.

Why the Performance Panel Is Not Always Sufficient?

The panel excels at identifying slow SQL queries and caching issues, but it does not show bottlenecks in asynchronous code or external API calls. For deep diagnostics, we additionally use Xdebug profiling and monitoring of REST services (e.g., 1C or payment gateways). The panel is the first line of diagnostics, not the last.

How Often Should Performance Audits Be Conducted?

We recommend keeping the performance monitor running continuously, and conducting a full audit quarterly or after major updates. This catches degradation early. For example, after adding a new catalog section or integrating a new API, check whether the number of SQL queries has increased.

What a Full Performance Audit Includes

If you entrust diagnostics to us, you get:

• A complete audit of current performance using the panel and additional tools.
• SQL query optimization: EXPLAIN analysis, index addition, ORM query refactoring.
• Cache tuning: tagged cache, HTML cache, composite mode.
• Performance monitor configuration for continuous metric collection.
• A final report with recommendations and an action plan.
• A guarantee on results — we will set target load time indicators.

. Order a preliminary free diagnostic using the performance panel. Contact us for a consultation on optimization.

SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME, NON_UNIQUE FROM INFORMATION_SCHEMA.STATISTICS WHERE TABLE_SCHEMA = 'your_database';