We need to rebuild our reporting database with over a year of data and don't want it to take a week to finish so we want to optimize this process. We currently have a standalone processing server for aggregation but want to set up multiple ones and increase the max aggregation threads from 1 to 4 on each server. In the documentation for rebuilding the database here - Walkthrough: Rebuilding the reporting database it says on step 5.

If you are configuring a dedicated server...{do stuff}...

But it doesn't say how to configure it if you have multiple servers for processing/aggregation.

What are the right settings for the App_Config/Include/Sitecore.Analytics.Processing.Aggregation.ProcessingPools.config?

  • Was your project successful? How does Sitecore distribute the work load between multiple processing servers? For example, having multiple processing servers, how does one know that the other processing server is processing or has processed the interactions during the reporting database rebuild?
    – Alex S
    May 2, 2017 at 15:33

2 Answers 2


In the documentation for Configuring a Sitecore Processing server it's mentioned that,

You can configure a processing server in much the same way as you configure a content delivery or content management server.

Basically, you need to review settings which identify the Instance uniquely which helps in EventQueue and similar stuff when setting up a cluster of Sitecore servers pointing to same SQL database.

One such setting which I know already is <setting name="InstanceName" value="" />. The default value of this setting is empty so Sitecore will take Computer Name when the value is empty.

Also, few not to miss recommendations from above link - when setting up a cluster of Processing servers.

  1. Setup Application initialization or the appropriate module (IIS 7.5), so you can successfully start Sitecore after you recycle the application pool. If you do not do this, Sitecore will not be launched and its application pool may shut down due to inactivity.
  2. Synchronize all servers to a single reliable time source for example Network Time Protocol (NTP)

Update: For correct settings for processing or aggregation instances or for Sitecore.Analytics.Processing.Aggregation.ProcessingPools.config, you can download the correct excel files, which goes with your Sitecore version, from here - Configure a processing server.

If it helps, to make your task easy there are some PowerShell scripts to configure server role (like cd, cm, processing, aggregation, reporting, etc) i.e. enabling/disabling .config files posted on this SSO question here. However configuring settings within a .config file is a manual effort in my knowledge.

  • I get that you're showing how to configure a clustered server role, but the question specifically asked what the right settings should be in the Sitecore.Analytics.Processing.Aggregation.ProcessingPools.config file for a clustered server. Can you add the requested clarification to your answer for that file? Mar 15, 2017 at 0:05
  • I didn't realize that before. I have updated the answer now. :)
    – Harsh Baid
    Mar 15, 2017 at 19:28

The Sitecore documentation page that you linked to actually does apply to situations where you have multiple, dedicated Processing servers.

I think what you are getting confused by is the singleInstance="true" property of the <history> node, as seen below:

<history type="Sitecore.Analytics.Data.MongoDb.ProcessingPool.MongoDbProcessingPool, 
  Sitecore.Analytics.MongoDb" singleInstance="true" >
  <param desc="connectionStringName">tracking.history</param>

This property is actually not what you think: it is used to tell Sitecore.Configuration.Factory that when it creates the instance of the specified type, it should create the instance as a Singleton, and thatall subsequent calls to create an instance of this type should use the existing Singleton instance.

  • So what you are saying is that each server should have the same configuration, and that each one should have singleInstance="true"? Mar 14, 2017 at 22:21
  • Correct. That setting actually helps performance on the instance itself. Personally, I think that Sitecore could have chosen a more clear name for the property (e.g. singleton, instantiateOnce, etc.). Still though, it's a good implementation and it gets the job done. Mar 14, 2017 at 22:22
  • 1
    OK, that makes sense. I agree the name could be more clear, but you have provided the information that we need. Thank you for the quick and informative response! Mar 14, 2017 at 22:23
  • No problem ;) Let me know if you have any issues Mar 14, 2017 at 22:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.