Scaling and configuring the xConnect Search Indexer
This topic explains how to configure the xConnect Search Indexer. In addition to the configuration settings discussed here, you can use additional settings to configure how it operates and how it interacts with the search provider you choose.
Scaling the xConnect Search Indexer
The following table describes the ways you can scale the xConnect Search Indexer:
Scaling option |
Supported |
Description |
---|---|---|
Combined instance |
Partially |
The xConnect Search Indexer is a worker role and cannot be combined with any other XP services. |
Standalone instance |
Yes |
You can deploy xConnect Search Indexer as:
|
High availability and failover |
Partially |
You can fail over to a passive instance of the xConnect Search Indexer. Note The xConnect Search Indexer does not have a health check API endpoint. You must use an external tool to monitor the WebJob or Windows Service health. |
Horizontal scaling for load distribution |
No |
We do not test or recommend running multiple active instances of the xConnect Search Indexer. Each instance would process the same contacts and interactions and put unnecessary load on the xConnect Collection Search service and the xDB Collection database. Also, the instances could potentially also interfere with each other on a data level producing undesirable results and failures. Keep the following in mind when scaling the xConnect Collection Search service:
|
Performance tuning
Consider the following performance tuning options:
-
Change tracking may cause high CPU usage by the underlying collection database. If this happens, consider modifying the tracking retention period.
-
If the xConnect Search Indexer is consuming too much memory, consider reducing the
SplitRecordsThreshold
setting until memory usage reaches a reasonable level.SplitRecordsTreshold
x number of cores determines the number of records that are loaded into memory. -
If reducing
SplitRecordsThreshold
does not improve memory usage, consider reducing theNumberOfChangeVersion
setting. -
If the indexer is consuming too much memory during index rebuild, consider reducing the
ParallelizationDegree
andBatchSize
settings. Keep in mind that new data continues to be indexed during an index rebuild.
See Configuring the xConnect Search Indexer for descriptions and locations of settings.
Security configuration tasks
Refer to the xConnect Search Indexer section of the Security guide.
Default topologies and packages
The following tables list the topologies that include the xConnect Search Indexer and how the role is packaged by default.
Sitecore Installation Framework
The xConnect Search Indexer is available in the following default topologies for SIF:
Topology |
Web Deploy Packages |
Description |
---|---|---|
XP Single |
|
The xConnect Search Indexer is bundled with all other XP service roles. The indexer is installed as a Windows Service and is physically located in the |
XP Scaled |
|
The xConnect Search Indexer is bundled with the xConnect Collection Search. The indexer is installed as a Windows Service and is physically located in the |
Sitecore Azure Toolkit
The xConnect Search Indexer is available in the following default topologies for SAT:
Topology |
Web Deploy Packages |
Description |
---|---|---|
XP Single |
|
The xConnect Search Indexer is bundled with all other XP service roles. The indexer runs as an Azure WebJob in the context of the combined application. |
xDB Single | ||
XP Scaled and xDB Scaled |
|
The xConnect Search Indexer is bundled with xConnect Collection Search. The indexer runs as an Azure WebJob in the context of the xConnect Collection Search application. |
Excluding the xConnect Search Indexer
The xConnect Search Indexer is a mandatory role if you are using the Experience Platform and cannot be excluded from any of the topologies that it is a part of.