As mentioned previously, the number of threads available, determines the number of actions that can be run at the same time.
Vertical Scaling of your environment allows you to have multiple threads on a server. Having multiple threads is convenient for simultaneously performing multiple tasks.
This is particularly useful when dealing with multiple site collections or sites. With multiple site collections or sites, you can have a different thread performing the processing for each site.
Replication functions optimally if it is capable of handling inbound and outbound processing on a web application simultaneously. For instance, in the following environment, an outbound event leaving Corporate has one thread available for processing, labeled T1, and an inbound event coming into Corporate from London has one thread available for processing, labeled T2. In total two threads are available for real-time bidirectional replication to take place. This environment would function with one available thread as well; however, processing would take longer as the same thread would be required to process outbound and inbound events on the web application.
If we add another farm into the mix, then replication may be slower with just two threads. In such a scenario Replicator will wait for all outbound processing to finish before inbound packages can be applied. This in turn slows down replication.
In the following scenario two threads may cause for slower processing, as an outbound event would require one thread to handle sending the package to London from Corporate, labeled T1, and another thread to send the package to Hong Kong from Corporate, labeled T2. This means that the threads are not available to processing potential incoming packages from London or Hong Kong, until outbound processing as completed. This in turn hinders the pace of replication, causing it to be slower.
In Replicator, the number of threads available for parallel processing is determined by the edition of Replicator. Express edition has 1 available thread, Standard has 2, and Enterprise has a default of 10 threads running on each replication engine, with the ability to increase to an unlimited amount of threads.
Consider the following factors found within your SharePoint environment that will use threading:
·Outbound or inbound processing.
·Classification queue numbers.
Each of these factors can be processed independently to distribute the load across multiple threads and will, therefore, determine the edition of Replicator that will best suit your environment. They also, therefore, determine how many threads you can take advantage of at a time.
Enterprise Edition has a default of 10 threads working at the same time. This number can be increased to an unlimited number of threads operating at the same time. This is particularly convenient in a hub-and-spoke architecture, where Enterprise edition is set up at the hub. With Enterprise edition you will be able to handing incoming and outgoing processes for multiple spokes, allowing Replicator to function in real-time, even in more strenuous scenarios.
It is, however, important to keep in mind that we are limited by the number of threads that you can take advantage of, as replication works in sequence order.
Enterprise edition is also the only edition which allows horizontal scaling. With this edition you can use multiple engines, thereby allowing you to disperse the load placed on any one machine by dividing the load of processing between them.
Advantages for having multiple replication engines in a farm include:
1.In the event that one of your servers stop, you have another which will insure the continuity of replication operations. This ensures high availability on your farms.
2.You spread the load of processing packages between multiple replication engines, allowing your machines to work faster due to parallel processing.
For example, you can shape your farm to have two Enterprise Replication engines running in parallel. You can specify that each engine handle a maximum of five threads at a time, thereby evenly distributing the load placed on each engine. In turn, both engines will be able to work faster, optimizing both your system as well as the functionality of Replicator.
NOTE: that horizontal scaling is entirely transparent to the user, and therefore the use has no control of it.
This section summarizes the capabilities of Metalogix Replicator.