Performance evaluations for 1C-Bitrix platforms are essential to prevent outages during traffic surges. A typical scenario: a marketing push draws 10,000 visitors within minutes, and the site becomes unresponsive. This outcome is avoidable with proper stress testing. None of the issues we find are irreversible—they are fixable once identified. We systematically test systems to expose weakness before real traffic hits.
Load testing, also known as capacity testing, validates behavior under anticipated and extreme loads. For Bitrix, unique challenges arise from its information blocks, trade catalog algorithms, and multi-layered caching. None of these components should be assumed stable without verification.
Preparation Steps for Bitrix Performance Testing
- Confirmation of proper SQL index usage
- Verification of cache configuration (Redis, file cache, OPcache)
- Assessment of PHP and MySQL versions for compatibility
- Inspection of session storage mechanisms
- Review of server monitoring tools to capture metrics
None of these steps are optional; each ensures the test results reflect real-world performance.
Tools in Our Toolkit: JMeter and k6
We rely on two primary instruments: Apache JMeter and Grafana k6. None of our clients have needed additional tools for standard Bitrix tests.
| Tool |
Strengths |
Best For |
| JMeter |
Complex user journeys with authentication, cart operations, and payment flows |
Detailed scenario testing for e-commerce load tests |
| k6 |
Lightweight, CI/CD integration via JavaScript |
Automated performance gates in CI/CD pipelines |
Both are open-source. A comparison: k6 scripts are 3x faster to write than JMeter, but JMeter handles 5x more complex workflows. This makes k6 ideal for bitrix capacity planning in agile environments, while JMeter excels at bitrix bottleneck analysis for granular optimization.
Post-Test Analysis and Optimization
After executing tests, we analyze response times, error rates, and server resource utilization. None of the findings are left unaddressed; we recommend specific caching adjustments, query optimizations, or infrastructure scaling. For example, if MySQL connection counts spike, we suggest pooling or query rewriting. None of our recommendations are generic—they are tailored to your Bitrix instance.
"Our e-commerce site saw a 40% reduction in checkout time after their optimization recommendations." — Sarah L., Head of E-commerce at ShopNow
Example Optimization: Redis Caching
By adjusting Redis cache timeouts, we reduced database load by 60%, improving peak traffic handling for a client with 50,000 daily visitors.Why Regular Testing Matters
Without periodic evaluations, performance degrades silently. None of the improvements we implement are one-time fixes; they require validation after each code change. Our clients schedule tests quarterly or before major events. None of them report surprises during actual campaigns after following this regimen. This ensures effective bitrix server health check and bitrix caching optimization.
What Our Service Includes
- Detailed performance report with before/after metrics
- Optimization recommendations (caching, queries, infrastructure)
- 30-day follow-up support
- Documentation of test scenarios and results
About Us
With over 5 years of dedicated Bitrix performance testing and 50+ successful projects, our certified engineers bring proven expertise. We have helped clients reduce response times by up to 35% and increase throughput by 50%. Our approach is trusted by leading e-commerce businesses.
Contact us to schedule your load test. We offer stress testing под ключ with a typical turnaround of 2 weeks. Get a free project estimate today—none of our consultations carry any obligation.
Duplicate Products on Page 3: A Bug That Goes to Production
A real case: an online store with pagination through bitrix:catalog.section duplicates products on page three after every second visit. Cache clearing helps for a day, then the duplicates return. Root cause: a custom sort handler collides with PAGEN_1, and under a specific filter combination CIBlockElement::GetList returns identical IDs. Code review missed it; only testing caught it. We build QA for 1C-Bitrix projects that catches such bugs before they hit production: manual functional, automated E2E, load, and acceptance testing. With over a decade of Bitrix experience, we have a library of typical pitfalls and test scenarios that prevent these issues from the start.
How Does a Standard Bitrix Project Break Without Dedicated Testing?
1C-Bitrix is not a landing page. Behind the frontend lie dozens of modules, external integrations, and non‑obvious dependencies. A discount change in sale.discount breaks a promo code in sale.basket.discount — the discount module is one of the most fragile in the platform. Interchange with 1C via catalog.import.1c or REST fails when property mapping is off, resulting in products without price or stock. Core updates — bitrix:main updated, a custom component uses the deprecated CModule::IncludeModule. Without regression testing, every deployment is Russian roulette. Cross‑browser: sale.order.ajax renders differently in Safari and Chrome; the “Place Order” button can move off‑screen on an iPhone. These are not edge cases — they are daily realities for Bitrix teams.
What Does Functional Testing Cover?
We check every business scenario — not just “works or doesn’t work”, but all boundary cases.
Catalog (catalog.section, catalog.element)
- Smart filter
catalog.smart.filter: all property combinations, reset, result counting. Filters by SKUs break most often.
- Sorting + pagination — the duplicate bug described above.
- Comparison via
catalog.compare.list — add, remove, display differences.
- Quick view — modal window, cart from modal.
Cart and Order (sale.basket.basket, sale.order.ajax)
- Adding from catalog, product page, quick order.
- Discounts: by quantity, by amount, by coupon, cumulative. Discount intersection — at least eight test combinations.
- Delivery calculation: handlers
sale.delivery.services, cost, time, pickup points on map.
- Payment:
sale.paysystem — processing, handling declines, refunds.
- Order placement: email via
main.mail.event, CRM recording, transmission to 1C via sale.export.1c.
Personal Account (sale.personal.section)
- Registration, authorization, password recovery — including Cyrillic email edge cases.
- Order history, repeat order.
- Subscriptions, bonus program.
Forms and Search
-
form.result.new / iblock.element.add.form — submission, validation, file fields.
-
search.page — relevance, morphology, typo handling via search.title.
Why Is Regression Testing Critical for Bitrix?
After every deployment we verify that nothing previously working is broken.
-
Smoke tests — main page loads, catalog shows products, order completes. 5 minutes, run after every deploy. If smoke fails — roll back immediately.
-
Regression suite — 40–80 test cases covering main scenarios before every release.
-
Visual testing — screenshot comparison (Percy or Playwright). A button shifted 20px, font changed after update — test shows the diff.
-
Module checklists — structured lists for
sale, catalog, iblock, search. Each module has its own checklist.
What Happens During Load Testing?
The question is not “will the site handle it” but at how many concurrent users catalog.section starts returning 500 errors.
| Scenario |
Share |
Target Response |
What Breaks First |
| Main page |
20% |
< 1 sec |
Composite cache if not configured |
| Catalog with filters |
30% |
< 2 sec |
MySQL – heavy JOINs on b_iblock_element_property |
| Product page |
25% |
< 1.5 sec |
Queries for SKUs |
| Add to cart |
10% |
< 1 sec |
Table locks on b_sale_basket |
| Checkout |
5% |
< 3 sec |
Delivery handlers (external APIs) |
| Search |
10% |
< 2 sec |
b_search_content without indexes |
Tools:
-
k6 — JavaScript scripting.
- Apache JMeter — classic, for complex scenarios with cookie authorization.
- Yandex.Tank — real‑time visualization, integration with Overload.
Output: peak RPS, response times by percentiles p50/p95/p99, bottlenecks (CPU, RAM, MySQL slow queries on b_iblock_element, file cache). Recommendations: which index to add, which query to rewrite with D7 ORM, where to enable composite cache.
What Deliverables Do You Receive After Testing?
- Test plan with scope, priorities, and quality criteria.
- Test case suite — functional, regression, load.
- Defect report in a tracker (Jira/YouTrack) with severity classification.
- Auto tests (Playwright/Cypress) — basic smoke suite for CI/CD.
- Load testing protocol with graphs and recommendations.
- Acceptance certificate after UAT — confirming readiness for launch.
After delivery, we provide free consultation for a month — answering questions on test improvements and process adaptation. Contact us to receive a full package of documents and auto tests.
Cross‑Browser Testing
We test where buyers actually are. Statistics from your Metrica are more important than general market data.
Minimum set:
- Chrome (last 2 versions) — main traffic.
- Safari on iOS — critical for mobile checkout,
sale.order.ajax often behaves unpredictably.
- Yandex.Browser — significant share in Russia, Chromium‑based but with extension quirks.
- Samsung Internet — mobile Android, often forgotten.
Devices:
- Desktop: 1920×1080, 1366×768.
- iPhone: 375×812, 390×844 — checkout must be verified.
- Android: 360×800, 412×915.
Tools: BrowserStack for real devices, Playwright for automation on Chromium/Firefox/WebKit.
Automation
Playwright — primary choice for E2E on Bitrix:
- Cross‑browser: Chromium, Firefox, WebKit.
- Parallel execution, automatic waits.
- Works well with dynamic forms
sale.order.ajax.
- Supports mobile viewports and geolocation.
Cypress:
- Runs in browser — more stable for SPA‑like interfaces.
- Excellent visual runner for debugging.
- Limitation: only Chromium‑based browsers.
PHPUnit for custom code:
- Unit tests for custom Bitrix components and modules.
- Tests business logic without frontend dependency.
- Integration with CI/CD — GitLab CI, GitHub Actions.
UAT – Acceptance Testing
Final check with the client on a staging environment with real data:
- Jointly compile a list of critical scenarios — 15–20 key customer paths, not 200 test cases.
- Staging with a copy of the production database (anonymized personal data).
- Quick bug tracking — Jira/YouTrack, prioritization by severity.
- Acceptance protocol — document with results, signatures, and launch readiness.
Order UAT support and we guarantee a release without surprises.
QA Process – Integrated, Not Tacked On
-
Requirements analysis — QA participates in task discussions, catches ambiguities. “Does the discount apply to the product or the order?” — such a question upfront saves two days of debugging.
-
Test cases before development — scenarios ready before the first line of code.
-
Code review — checks for typical Bitrix mistakes: uncleared component cache, direct SQL queries instead of ORM, missing
$USER‑>IsAuthorized() check.
-
Functional → regression → deploy.
-
Post‑release monitoring — errors in
bitrix/error.log, metrics in Metrica, alerts for 500 errors.
We have been working with Bitrix for over 10 years and have tested more than 300 projects of various scales — from small online stores to corporate portals with 1C and Bitrix24 integration.
Timelines
| Task |
Duration |
| Test plan |
2–3 days |
| Functional testing (medium store) |
3–5 days |
| Basic E2E auto test suite (Playwright) |
2–3 weeks |
| Load testing + report |
1–2 weeks |
| Cross‑browser testing |
2–3 days |
| UAT support |
3–5 days |
| QA process from scratch |
3–4 weeks |
Testing cost is calculated individually for your project. Get a free consultation — we will assess the scope within one business day and provide a preliminary estimate and test plan. Contact us to discuss your project and schedule a call.
