Avoiding Task Execution on the Local Machine
Occasionally, the Agent initiating the build may suffer from a high I/O load as a result of having to manage both file synchronization to and from remote Agents and writing the build’s output to disk. This is especially relevant in the following scenarios:- The initiating machine is utilizing more than one CPU for builds.
- A large number of remote Agents are set to participate in the build.When this is the case, it may be beneficial to prevent the Agent that initiated the build from executing tasks that can also be run by remote Agents – compilation of source files, for example, in order to allow it to dedicate its resources entirely to build management and file synchronization.
Restarting Remote Processes on the Local Machine When Possible
The Restart remote processes on local machine when possible option enables a “competition mode” (also referred to as double targets), in which a task that is already running on a remote Agent is started a second time, in parallel, on the initiating machine. The two copies race each other, and the output of the first one to complete is applied to the build. This option is disabled by default.Competition Mode vs. Normal Local Execution
These two behaviors are easy to confuse:- Normal local execution – Unless Avoid task execution on local machine when possible is enabled, the initiating Agent already uses its free local cores to run new waiting tasks alongside the remote Agents. This is ordinary scheduling, and it happens whether or not competition mode is enabled.
- Competition mode – When this option is enabled and the initiating machine still has spare capacity after normal scheduling, Incredibuild may additionally start a second copy of a task that is already executing remotely, rather than picking up a different waiting task.
How Competition Mode Works
The option exists to prevent a build from waiting on one slow remote machine while the initiating machine sits idle:- A task is assigned to a remote Agent and starts running there.
- If the initiating machine has idle capacity, Incredibuild starts the same task locally as well. Only tasks that are still executing remotely and have not yet begun writing their output are eligible; some task types are excluded from doubling altogether.
- The two copies race. The output of the first copy to complete is applied to the build.
- For eligible tasks, the remote copy may be cancelled once the local copy has completed first.
When Not to Use Competition Mode
Competition mode is only worthwhile when the initiating machine genuinely has resources to spare. If the initiating machine is under significant load of any kind – CPU, memory, disk I/O, or heavy file synchronization and output writing – this option should not be used, as in this case the competition mode is not efficient: the duplicated tasks compete with build management for the same resources and can slow the build down.Enabling the Option
Enable or disable the option in the Agent Settings dialog box, on the Initiator->General page, under Distribution: Restart remote processes on local machine when possible. The corresponding registry value isAllowDoubleTargets (REG_DWORD), under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Xoreax\Incredibuild\Builder. Set it to 0 to disable competition mode (the default) or to 1 to enable it.
Competition mode cannot be combined with Build Cache. When Build Cache initializes successfully for a build, Incredibuild automatically disables double targets for that build and writes the warning
Disabling DoubleTasks with BuildCache to the build’s event log. This is a per-build override only: the Agent Settings checkbox and the AllowDoubleTargets registry value are left unchanged. To use competition mode, run the build without Build Cache.Utilizing Multiple CPUs/Cores
Incredibuild can utilize multiple CPUs and cores when executing a distributed process. This requires the purchase of a Multi-CPU license for each machine with multiple CPUs/cores (in trial licenses, all Agents automatically utilize up to eight available CPUs and cores). Once this is done, distributable tasks are run using each of the available CPUs/cores, depending on each Agent’s current availability. If the machine’s hardware supports Hyper threading, it is possible to use all logical cores in order to improve performance. This can be set under Agents Settings -> Agent -> CPU Utilization.Moving your Build’s Output Folder to a Fast-performing File System Location
In builds involving a large amount of output data, writing the build’s output files to disk can become a bottleneck and slow down the distribution process. This is especially relevant in the following scenarios:- The Initiating machine is utilizing more that one CPU for builds.
- A large number of remote Agents are set to participate in the build.In these cases, it can be very beneficial to set the project’s output folders to a location that will perform as fast as possible. An ideal location for the project’s output file would be a local, high-performance drive that is not running the Windows system.
Minimizing Directory Access
In certain environments, a performance gain can be obtained by minimizing the number of accesses to directories performed during builds. This is especially common in the following scenarios:- Builds that store input files in network-based file systems.
- Projects using an input file directory tree, which spreads over an unusually large number of directories.