Sphinx Search for 1C-Bitrix: Setup, Morphology, and Delta-Indexation

Why standard Bitrix search fails with a large catalog?

A catalog of 200,000 items — the standard Bitrix search returns a page in 5 seconds, filtering by properties takes even longer. The standard search module uses b_search_* tables, which are not optimized for complex filtering by multiple properties or full-text search with morphology. Sphinx solves both problems: incremental indexing, morphology, and faceted search. We configure it turnkey in 3–10 days. The engine reads data directly from MySQL, simplifying integration: you don't need to write an exporter — the data source is described via SQL queries in the Sphinx config.

For example, in an auto parts e-commerce project with a catalog of 350,000 items, after deploying Sphinx, search time dropped from 8 seconds to 50 ms, and filtering by 12 properties became instant. We have implemented Sphinx in 30+ Bitrix projects with catalogs ranging from 10,000 to 500,000 items. We guarantee stable operation and post-launch support. Contact us — we will work out the search architecture for your project.

How to configure the data source for Sphinx?

Sphinx reads data via a source — an SQL query executed during reindexing. Example config for a product catalog:

source bitrix_catalog
{
    type            = mysql
    sql_host        = localhost
    sql_user        = bitrix
    sql_pass        = password
    sql_db          = bitrix_db
    sql_port        = 3306

    sql_query = \
        SELECT \
            e.ID, \
            e.IBLOCK_ID, \
            e.NAME, \
            e.DETAIL_TEXT, \
            e.CODE, \
            UNIX_TIMESTAMP(e.TIMESTAMP_X) AS updated_at \
        FROM b_iblock_element e \
        WHERE e.IBLOCK_ID IN (5, 6) \
          AND e.ACTIVE = 'Y' \
          AND e.WF_STATUS_ID = 1

    sql_attr_uint  = IBLOCK_ID
    sql_attr_uint  = updated_at
    sql_field_string = NAME
}

sql_attr_uint declares numeric attributes for filtering, sql_field_string declares a string field for search and display. Sphinx supports up to hundreds of attributes without performance loss.

Connecting product properties for faceted filtering

For faceted filtering, add properties via sql_attr_multi:

sql_attr_multi = uint PROPERTY_COLOR FROM query; \
    SELECT e.ID, p.VALUE_NUM \
    FROM b_iblock_element e \
    JOIN b_iblock_element_prop_s5 p ON p.IBLOCK_ELEMENT_ID = e.ID \
    WHERE e.IBLOCK_ID = 5

The table b_iblock_element_prop_s5 corresponds to infoblock ID 5. This is a Bitrix feature: each infoblock has its own property table. In complex projects, we combine several tables via UNION. You can also index multiple properties via sql_attr_multi with delimiters, enabling filtering by several values simultaneously.

How to configure Russian morphology?

Sphinx supports Russian via a built-in stemmer. Index configuration:

index bitrix_catalog
{
    source          = bitrix_catalog
    path            = /var/lib/manticore/bitrix_catalog
    morphology      = stem_ru, stem_en
    min_word_len    = 2
    charset_table   = 0..9, A..Z->a..z, a..z, U+410..U+42F->U+430..U+44F, U+430..U+44F
    min_prefix_len  = 3
}

min_prefix_len = 3 enables prefix search: "ноут" → "ноутбук". This increases the index, but we always optimize for your data volume. For large catalogs (over 300,000 items) we recommend dropping prefix and using infix search. The charset_table setting ensures correct Cyrillic handling and case insensitivity.

PHP client and queries from Bitrix

Sphinx uses the MySQL protocol, so we access it via PDO:

$sphinx = new PDO('mysql:host=127.0.0.1;port=9306', '', '');

$stmt = $sphinx->prepare(
    "SELECT id, weight() as w, NAME
     FROM bitrix_catalog
     WHERE MATCH(:query) AND IBLOCK_ID = :iblock
     ORDER BY w DESC
     LIMIT :offset, :limit
     OPTION max_matches=1000"
);
$stmt->execute([
    ':query'  => $searchQuery,
    ':iblock' => CATALOG_IBLOCK_ID,
    ':offset' => ($page - 1) * $pageSize,
    ':limit'  => $pageSize,
]);

$ids = array_column($stmt->fetchAll(), 'id');

Once you have $ids, load full data via CIBlockElement::GetList(). This is the standard pattern we use in all projects. To speed up, you can cache the result IDs for 5–10 minutes. For high query volumes, we recommend a PDO connection pool.

How to set up delta-indexation for up-to-date data?

Full reindexation (indexer --all) — for nightly cron tasks. Delta index — indexes only records changed since the last indexation. Requires an updated_at field and a separate source:

source bitrix_catalog_delta : bitrix_catalog
{
    sql_query = \
        SELECT e.ID, ... \
        FROM b_iblock_element e \
        WHERE UNIX_TIMESTAMP(e.TIMESTAMP_X) > (SELECT max_doc_date FROM sph_counter WHERE id=1)
}

Merge: indexer --merge bitrix_catalog bitrix_catalog_delta. Delta-indexation runs every 5–10 minutes via cron. We also configure sph_counter to correctly track the last indexation time. If cron fails, a full reindexation runs automatically.

Why Sphinx and not Elasticsearch?

Sphinx indexes data from MySQL 2–3 times faster on servers with 2 CPU and 4 GB RAM. Comparison for a typical Bitrix catalog:

Choose Sphinx if your server has < 4 GB RAM and data comes only from MySQL. Elasticsearch is better for clusters and real-time aggregations. In 80% of our Bitrix projects, we use Sphinx. Learn more about Sphinx on Wikipedia.

What typical errors occur when setting up Sphinx?

The most common is an incorrect charset_table: if Cyrillic is not specified, searches for Russian words return empty results. The second most common is missing sql_attr_multi for properties: faceted filtering stops working. The third is a too large min_prefix_len: for catalogs >500,000 items, the index grows 2–3 times and indexing time increases. In every project, we audit the configuration and perform load testing to eliminate these issues.

What is included in the integration

• Analysis of catalog structure and search requirements
• Deploy Sphinx (Manticore) on the server
• Configure data sources (infoblocks, properties, hl-blocks)
• Set up indexes with morphology and prefix search
• Develop a PHP gateway for queries from Bitrix
• Integrate with the catalog component (faceted search, filter)
• Implement delta-indexation (data freshness)
• Test under load
• Documentation and administrator training
• 12-month warranty on all work

Timelines and pricing

Pricing is calculated individually after analyzing your project. We assess data volume, facet complexity, and speed requirements. Order the integration — get a consultation on search architecture. Certified specialists with 7+ years of experience guarantee stable operation and post-launch support.

80% of Bitrix sites slow down due to one table

b_iblock_element_property is an EAV structure where each row stores one value of one property of one element. A catalog of 50,000 products with 30 properties yields 1.5 million rows. The smart filter performs a JOIN of this table with b_iblock_element on five properties, and MySQL performs a full table scan for 3–5 seconds. Our experience shows that without intervention in this table, site acceleration is impossible. We take on projects where load time has dropped to 8–10 seconds and bring TTFB back to <200 ms within 1–2 weeks. Site speed optimization begins with an audit of slow queries and ends with a comprehensive turnkey infrastructure overhaul.

Contact us for an audit — we will identify bottlenecks within 2 hours and propose a concrete plan.

How to achieve TTFB below 200 ms?

Server optimization is the first step. Nginx configuration goes beyond simple gzip. Specifically:

• gzip_comp_level 4-5 — higher is pointless, CPU consumes more than it saves bandwidth.
• brotli on with brotli_static on for precompressed files.
• HTTP/2 with http2_max_concurrent_streams 128.
• fastcgi_cache for PHP responses — caching at Nginx level, bypassing PHP-FPM entirely.
• worker_processes auto, worker_connections according to the number of simultaneous connections.

PHP-FPM tuning: choose between pm = dynamic and pm = static. Static mode works best for dedicated servers with predictable load because it avoids forking overhead. Dynamic saves RAM under low traffic. Calculate pm.max_children as (available RAM - RAM for MySQL/Redis) / average process consumption. For OPcache set memory_consumption=256, max_accelerated_files=20000, and validate_timestamps=0 in production (restart PHP-FPM on deploy).

MySQL/MariaDB: the main bottleneck is almost always the database. Enable slow_query_log with a threshold of 0.5 sec and analyze every query via EXPLAIN. Set innodb_buffer_pool_size to 70–80% of available RAM on a dedicated server. Create composite indexes for faceted search: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) on b_iblock_element_property. Run OPTIMIZE TABLE b_iblock_element_property after mass operations.

How to configure three-level caching?

Managed component cache. Set TTL individually for each component. Catalog — 3600 sec, news feed — 300 sec, banners — 86400. The same TTL everywhere guarantees either outdated data or useless cache.

Composite cache. The bitrix:composite technology lets Nginx serve ready HTML from a file; PHP is not executed. Dynamic zones (cart, authorization) are loaded via AJAX request through CBitrixComponent::setFrameMode(true). TTFB drops below 50 ms. However, not all components are compatible; $APPLICATION->ShowPanel() and direct output via echo break the composite. We check every page through the panel 'Performance → Composite Site'. According to Bitrix official documentation on composite cache, this is the most effective caching method for high‑load projects.

Comparison: composite cache is 10–20 times faster than managed cache in time to first byte.

Memcached / Redis. Transfer cache from the file system: sessions go to Redis (session.save_handler = redis) — 10–50 times faster than files, plus cluster support. Component cache goes to Memcached via .settings.php: 'cache' => ['type' => 'memcache']. Also enable ORM query cache so identical GetList() calls don't hit MySQL on every request.

What is the fastest way to optimize Bitrix database?

Default MySQL settings are insufficient. Indexes — composite for faceted search, covering for frequent queries. MySQL responds from the index without accessing the data. Partial indexes (MariaDB) for filtering by ACTIVE = 'Y'. Audit unused indexes — each slows down INSERT/UPDATE.

Partitioning. For tables with millions of rows: b_stat_session, b_search_content_stem, and highload-blocks with history. Partition by date — a query for 'orders in a month' does not scan three years of data. Partitioning also solves the problem of concurrent queries during exchange with 1С via CommerceML.

Real case: a catalog of 200,000 products, 50 properties. Filtering by 10 properties took 12 seconds. After creating composite indexes on (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) and partitioning b_iblock_element_property by IBLOCK_ID, execution time dropped to 0.3 seconds. MySQL load decreased by 40 times.

Cleanup. Over a year or two, any database accumulates: outdated search index, expired records in b_cache_tag, history in b_iblock_element_prop_s*, logs in b_event_log taking gigabytes. We set up regular cleanup via agents.

Frontend and CDN

Images account for 60–80% of page weight. Convert to WebP via CFile::ResizeImageGet() with BX_RESIZE_IMAGE_PROPORTIONAL + conversion. Use srcset + sizes — never load a 3000px image into a 400px block. Add loading="lazy" for everything below the fold. AVIF offers another 20–30% savings vs WebP.

CSS/JS optimization: use the built-in Bitrix module to merge and minify via 'Settings → CSS/JS Optimization'. Apply PurgeCSS / UnCSS — in a typical Bitrix project, 60–70% of CSS is unused. Use defer / async for non‑critical JS and inline critical CSS in <head> for instant FCP.

Fonts: add <link rel="preload" as="font" crossorigin> for the main font. Set font-display: swap — text visible immediately. Subset via pyftsubset — keep only Cyrillic + Latin, file size reduces by 3–5 times.

CDN: Cloudflare, BunnyCDN, AWS CloudFront, or Russian providers (Selectel CDN, VK Cloud CDN). Serve static assets (CSS, JS, images, fonts) via CDN with Cache-Control: public, max-age=31536000, immutable for files with a hash. Use on‑the‑fly image optimization (imgproxy, Cloudflare Polish) without load on origin.

Why is load testing necessary?

Not synthetic benchmarks, but real scenarios: k6 / wrk to simulate routes — catalog → filtering → product card → cart → checkout. Measure RPS, response time (p50, p95, p99), error rate. Use Xdebug (callgrind) or Blackfire for PHP profiling to find bottlenecks. The test result gives an objective picture of where it actually slows down, not where it 'seems'. After optimization, run again to record improvements.

Results

What is included in the work?

1. Current performance audit — analysis of slow queries, PHP profiling, check of caching, CDN, server settings.
2. Server configuration — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Caching optimization — managed cache, composite site, TTL configuration, tagged caching.
4. Database work — index creation, partitioning, cleanup, EAV table reorganization.
5. Frontend — images (WebP/AVIF), CSS/JS (minification, deferred), fonts (preload, subsetting).
6. CDN — connection, caching rule setup.
7. Load testing — real user scenarios, metric report.
8. Documentation — description of all changes, recommendations for further maintenance.
9. Guarantee — support for 1 month after delivery, ensuring all optimizations are stable.

Monitoring

Without monitoring, everything degrades in six months. A new module, uncleared logs, a template change — and speed returns to original. Use web-vitals API for Real User Monitoring from actual visitors. Set up synthetic monitoring with Pingdom or UptimeRobot for regular checks from different locations. Configure alerts — TTFB > 500 ms or LCP > 3 sec triggers notification.

Timelines and cost

Cost is calculated individually after the audit. Get a consultation for your project — we will evaluate the current state and propose an acceleration plan with specific timelines and budget. We are a team with 12+ years of experience in Bitrix, having completed over 300 site speed optimization projects. Contact us to start the performance audit today.