Configure aggregation agents

Current version: 8.1

When you configure a processing server, to optimize performance, you may need to change the number of aggregation agents or threads that you run. Aggregation agents pick up interactions to be processed by the aggregation pipeline and convert data into a form suitable for use by the reporting database.

To configure aggregation agents or threads on a processing server:

  1. Open the Sitecore.Analytics.Processing.Aggregation.Services.config file in an XML editor. You can specify how many aggregation agents you want to run at the same time. Start by using the default settings.

  2. Edit the <MaxThreads> setting to specify the number of aggregation agents (threads) that you want to run on the server. You can also specify how many cleanup and recovery threads that you need. Adjust these settings depending on your available hardware and business requirements.

    Based on experience, the best performance is achieved when the amount of threads is equal to the number of logical CPU cores multiplied by a factor from 4 to 8. There is a strong dependency on the latency between the SQL Server and the MongoDB servers.

    Use the default values and then, over time, adjust these settings to optimize your aggregation server or servers.

    RequestResponse
          <!-- Aggregation Module: -->
    <module type="Sitecore.Analytics.Aggregation.AggregationModule" singleInstance="true">
    <BackgroundServices hint="list:Add">
    <aggregator type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/aggregator</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </aggregator>
    <contactProcessing type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/contactProcessing</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </contactProcessing>
    <cleanup type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/cleanup</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </cleanup>
    <recovery type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/recovery</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </recovery>
    <rebuild type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/rebuildAgent</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </rebuild>
    <history type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/historyWorker</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </history>
    <historyCompletionCheck type="Sitecore.Analytics.Core.BackgroundService">
    <param desc="agentName">aggregation/historyCompletionCheck</param>
    <Interval>0.00:00:15</Interval>
    <MaxThreads>1</MaxThreads>
    </historyCompletionCheck>
    </BackgroundServices>
    </module>
  3. Adjust the Max Pool Size property for the reporting database. The pool capacity should be at least about 120% of the number of agents (including processing, history, automation workers, and clean-up) that you have configured. This setting ensures that each thread has its own dedicated connection and will not have to wait for another thread to release its connection before running.

  4. To set the pool size, open the reporting database connection string configuration file, add the Max Pool Size property and set an appropriate value.

This table describes the purpose of each agent:

Agent

Description

aggregation/aggregator

Processes interactions during live aggregation. The more threads used, the faster data about new interactions will appear in the reporting database. If there is little traffic on the website and few new interactions you can allocate fewer threads.

aggregation/contactProcessing

Processes contacts. It is very similar to the aggregator, except it executes contacts pipeline for new contacts.

aggregation/cleanup

Obsolete, so do not allocate more than 1 thread for it.

aggregation/recovery

Obsolete, so do not allocate more than 1 thread for it.

aggregation/rebuildAgent

Executes the steps needed for rebuilding the reporting database. Do not allocate more than 1 thread for it.

aggregation/historyWorker

Main actor in a History rebuild. Allocate the maximum number of threads you can before a rebuild. When the rebuild finishes, you can set it back to one because this agent is only active during a History rebuild.

aggregation/historyCompletionCheck

Checks if all history worker agents have finished processing interactions. When they have, it marks the History Rebuild process as completed. One agent is enough.

Do you have some feedback for us?

If you have suggestions for improving this article,