Processing Multiple Tasks Simultaneously

System Manager supports executing tasks in parallel in a workflow. This takes advantage of a system's processing power to complete the tasks more quickly. This is done by using the split execution process. With a split execution process, you can have a workflow process two or more tasks at the same time. The split execution process shown below takes a linear workflow and begins to process three tasks in parallel.

When using split executions to process multiple tasks in a workflow at the same time, consider the following best practices:

• Ensure that the tasks do not depend on each other. Workflows are often linear processes that require that one task is completed before starting another task. For example, you cannot run certain Command Manager scripts until Intelligence Server is started. This means a task to start Intelligence Server should not be done in parallel with other tasks that require Intelligence Server to be operational.
• Consider the amount of processing that is required to perform the tasks in parallel, relative to your available system resources. While performing multiple tasks at once can save time, it can also slow down overall performance if the required system resources are not available. Even if a workflow is created to start multiple tasks, you can limit the number of tasks that are performed in parallel to prevent overloading the system, as described in Limiting the Number of Parallel Tasks to Prevent Over Consumption of System Resources.
• Split execution processes can use only the continue connector (see Using Connectors to Create the Logical Order of a Workflow) to link to new tasks to perform in parallel. You must also use two or more continue connectors, as a split execution is meant to split a workflow into at least two paths to perform in parallel.

Once a workflow execution is split into multiple paths, each task is performed independently of the other tasks. However, while the tasks are done independently, all the tasks may need to be completed before performing other tasks later in the workflow. For example, you can create a DSN and start Intelligence Server as separate tasks at the same time, but you may need both of those tasks to be fully complete before starting another task that requires the DSN to be available and Intelligence Server to be operational. To support this workflow, you can use the merge execution process to combine multiple paths back into one workflow path. For example, the merge execution process shown below combines the three tasks performed in parallel back into one execution after the three tasks are completed.

For each merge execution process, you must supply a time out value. This time out value is the amount of time, in seconds, that is allowed to complete all the parallel tasks that are connected to the merge execution process. The time starts to count down once the first task connected to a merge execution process is completed. How the remaining tasks connected to the merge execution are processed depends on the connectors used to continue from the merge execution process:

It is recommended that you use the success and failure connectors to exit the merge process:

• Success connector: If each task that is connected to a merge execution is completed in the allotted time, the workflow continues to the configuration that is linked to the merge execution with the success connector.
• Failure connector: If at least one task connected to the merge execution is not completed in the allotted time, or all other paths have been ended without reaching the merge execution process, the workflow continues to the configuration that is linked to the merge execution with the failure connector.

Although merge execution processes are helpful to continue the workflow when certain tasks are completed, you do not have to merge any or all paths that are started with a split execution process. Each task performed in parallel with other tasks can come to separate completions using standard exit processes (see Using Exit Processes to End a Workflow). For example, in the workflow shown below, both DSN creation configurations must be completed to also process the Execute SQL configuration. However, the path that starts with an Intelligence Server startup configuration continues on to completion regardless of whether any of the other tasks are completed.

Limiting the Number of Parallel Tasks to Prevent Over Consumption of System Resources

While creating a workflow, the split execution process can be used to start as many tasks at the same time as required. However, each additional task that is attempted in parallel requires additional system resources. If your system cannot handle the additional processing requirements to complete all the tasks in parallel, this can slow down the workflow execution and the entire system's performance.

To avoid these types of performance issues, you can limit the number of tasks that can be processed at the same time for a workflow. This ensures that even if a workflow requests a certain number of tasks to be processed at the same time, only the specified limit is allowed to run at a time.

The default value for the limit is the greater of either the number of CPUs for the system or 2. Although the number of CPUs for the system is a reasonable default, be aware of the following:

• Systems can process more tasks simultaneously than the number of CPUs available.
• Systems can have multiple CPUs, but this does not necessarily mean all the CPUs are available to the user who is deploying a workflow. For example, consider a Linux machine with eight CPUs available. In this scenario, the Maximum Thread default value is 8. However, the user account that is being used to deploy the workflow may be allowed to use only one CPU for the Linux machine. When determining the maximum number of tasks to run simultaneously in System Manager workflows, you should understand details about system resource configuration.

As a workflow is deployed, any tasks over the set limit are put into a queue. For example, if a split execution process attempts to start five tasks, but the Maximum Threads option is set at three, two of the tasks are immediately put in the queue. Once a task is completed, the next task in the queue can begin processing.

In terms of queueing and processing tasks, each separate configuration is considered as a separate task. Once a configuration is completed, the configuration that it links to next might not be the next configuration to be processed. For example, a split execution process attempts to start five tasks, as shown in the image below.

The Maximum Threads option is set at three, which means that two of the tasks are immediately put in the queue. Assume then that one of the three tasks being processed (Task A) comes to completion, and it links to another task in the workflow (Task B). Rather than immediately starting to process Task B, the workflow must first process the tasks that were already included in the queue (Task E and Task F). This puts Task B behind the two existing tasks already in the queue.

To Define the Parallel Task Limit

1. From the View menu, select Options
2. In the Maximum Concurrent Threads field, type the maximum number of tasks that can processed at the same time. The default value for this option is the greater of either the number of CPUs for the system or 2.
3. Click OK.