Elasticsearch Reindexing Optimization for 1C-Bitrix
On a project with an 800,000 SKU catalog, a full Elasticsearch reindex from 1C-Bitrix took 14 hours. During that time, a queue of changes accumulated, search returned stale results, and the 1C import competed with indexing for server resources. Moreover, on each refresh during indexing, search locked for milliseconds, causing delays up to 3 seconds for an e-commerce store with a peak load of 10,000 requests per minute. Our goal was to cut the full reindex to 1–2 hours with zero search downtime. After optimization, server infrastructure costs reduced by $2,000/month, and the project savings paid back within 3 months. Our experience with catalogs up to 2 million items guarantees this result. This situation is familiar to many: the larger the catalog, the slower the standard mechanisms. But the solution lies in proper Elasticsearch configuration and indexer code optimization.
Why Does Reindexing Slow Down?
Typical causes of slow indexing: sequential single PUT requests for each document, forced refresh after each batch, and the default refresh_interval of 1 second. Each refresh creates a new Lucene segment, which then must be merged. On an 800k SKU catalog, this generates hundreds of thousands of small segments, and Elasticsearch spends resources merging them.
Zero-Downtime Reindexing Strategy
The key technique is to index into a new index rather than over the active one. The current index bitrix_catalog_v1 serves search via an alias bitrix_catalog. In parallel, we build bitrix_catalog_v2. Once reindexing completes, we atomically switch the alias—search moves to the new index without interruption.
Which Elasticsearch Settings Accelerate Indexing?
Before bulk indexing, we temporarily change parameters:
PUT /bitrix_catalog_v2/_settings { "index": { "refresh_interval": "-1", "number_of_replicas": 0, "translog.durability": "async", "translog.sync_interval": "30s" } } Disabling refresh (-1) speeds indexing 3–5 times because documents don’t appear in search until explicitly refreshed. Disabling replicas (number_of_replicas: 0) reduces cluster load. Async translog flushes to disk every 30 seconds instead of after each operation. After indexing, we restore standard settings and run forcemerge to consolidate segments into one.
How to Optimize the PHP Indexer?
We use the Bulk API with batches of 500 documents (5–15 MB). This is 10–20 times faster than single requests. Bulk API is the standard practice for bulk loading.
$batchSize = 500; $bulk = []; foreach ($products as $product) { $bulk[] = ['index' => ['_index' => 'bitrix_catalog_v2', '_id' => $product['ID']]]; $bulk[] = buildDocument($product); if (count($bulk) >= $batchSize * 2) { $client->bulk(['body' => $bulk]); $bulk = []; } } if (!empty($bulk)) { $client->bulk(['body' => $bulk]); } Parallel indexing via multiple processes: split the catalog by ID ranges. Three processes on a three-node cluster give linear acceleration. The bottleneck is MySQL read speed.
What Does Parallel Indexing Achieve?
Combining bulk API and parallel indexing accelerates indexing 10–20 times compared to sequential single requests. On our project, full reindex dropped from 14 hours to 1 hour 20 minutes.
Switching the Alias
After indexing, we atomically switch the alias:
POST /_aliases { "actions": [ { "remove": { "index": "bitrix_catalog_v1", "alias": "bitrix_catalog" } }, { "add": { "index": "bitrix_catalog_v2", "alias": "bitrix_catalog" } } ] } The operation takes milliseconds, and search continues uninterrupted.
Full Reindexing Scenario Example
- Create a new index with optimized settings.
- Set an alias on the current index.
- Launch parallel indexing processes with bulk API.
- After completion, switch the alias to the new index.
- Restore settings (refresh_interval, replicas) and run forcemerge.
Before vs. After Optimization
| Parameter | Before Optimization | After Optimization |
|---|---|---|
| Full reindex (800k SKU) | 14 hours | 1 h 20 min |
| Incremental update | 15–20 docs/s | 200–300 docs/s |
| Search downtime | Yes | None |
| Monthly cloud costs (est.) | $3,500 | $1,500 |
Service Scope and Pricing
Our turnkey optimization service is typically delivered within 3–10 business days. It includes:
- Audit of current Elasticsearch configuration and PHP indexer
- Index and mapping setup tailored to typical queries
- Optimization of bulk API and parallel processing
- Implementation of zero-downtime with aliases
- Maintenance documentation
- Consultation and training for your team
The service cost is determined individually after the audit. We provide a precise estimate within 2 business days. Write to us for a free project evaluation and get a detailed optimization plan.
Guaranteed Result
Our team has over 10 years of Bitrix development and has completed 500+ search performance optimizations for catalogs ranging from 10k to 2M SKUs. For each project, we conduct load testing and guarantee indexing speed. Elasticsearch is the de facto standard for high-load catalogs. Contact us to evaluate your project—we'll prepare an optimization plan and a fixed-price quote. Order our optimization service and achieve 7x+ faster indexing with zero downtime.
Optimization Timeline
Typical project duration is 3 to 10 business days, depending on catalog complexity and current settings. Exact timelines are determined after the initial audit. Server resource savings and reduced infrastructure costs often repay the investment within a few months.