Cost-Based Optimization of Integration Flows - Datenbanken ...

3.4 Optimization Techniques
One of the core concepts is to leverage parallelism of operator execution in order to
minimize the execution time. Due to typically low CPU utilization reasoned by (1) singlethreaded,
instance-based plan execution, (2) significant waiting times for external systems,
and (3) IO-bottlenecks for message persistence, these decisions are made with cost-based
optimality conditions rather than statically during the initial deployment.
Rescheduling the Start of Parallel Flows
The technique WC1: Rescheduling the Start of Parallel Flows rewrites existing Fork operators.
The execution time of the Fork operator o is determined by its most time-consuming
subflow r i with
⎛
⎞
W (o) =
max
|r|
i=1
∑m i
⎝ W (o i,j ) + i · W (Start Thread) ⎠ (3.16)
j=1
because the individual subflows are started in sequence and temporally joined (synchronized)
at the end of this operator.
The core principle of this technique is to reduce waiting time by rewriting the concurrent
subflows such that the subflows are started in descending order of their execution time.
In other words, the start sequence of parallel subflows is optimal if the condition Ŵ (r i) ≥
Ŵ (r i+1 ) holds, where Ŵ (r i) = ∑ m i
j=1 Ŵ (o i,j). The execution time can be reduced by (|r|−
1)·W (Start T hread), where W (Start T hread) denotes the constant costs for creation and
start of a thread.
The rewriting algorithm essentially consists of two steps. First, for each subflow, we
recursively sum up the costs of all individual operators. Second, we check if the optimality
condition holds and order the subflows according to the estimated costs if required. The
time complexity of this algorithm is given by O(|r| · log|r|).
Example 3.9 (Rescheduling Parallel Flows). Assume our example plan P 7 and the monitored
execution times shown in Figure 3.12(a). Furthermore, assume the cost for starting
of a parallel subflow (thread) to be W (Start T hread) = 3 ms. The estimated costs of the
Fork operator are then given by Ŵ (o 2) = 2 · 3 ms + 230 ms = 236 ms. Rescheduling the
parallel flows yields the alternative plan shown in Figure 3.12(b). Using this plan, the
costs are reduced to Ŵ (o 2) = 3 ms + 230 ms = 233 ms.
Fork (o2)
Fork (o2)
5ms
10ms
7ms
4ms
10ms
4ms
5ms
7ms
Assign (o3)
Assign (o6)
Assign (o9)
Assign (o11)
Assign (o6)
Assign (o11)
Assign (o3)
Assign (o9)
130ms
150ms
90ms
120ms
150ms
120ms
130ms
90ms
Invoke (o4)
Invoke (o7)
Invoke (o10)
Invoke (o12)
Invoke (o7)
Invoke (o12)
Invoke (o4)
Invoke (o10)
70ms
Translation
(o5)
205ms
70ms
Translation
(o8)
230ms
97ms
85ms
Translation
(o13)
209ms
70ms
Translation
(o8)
85ms
Translation
(o13)
70ms
Translation
(o5)
230ms 209ms 205ms 97ms
(a) Plan P 7
(b) Optimized Plan P ′ 7
Figure 3.12: Example Rescheduling Parallel Flows
Clearly, the benefit of this optimization technique is limited but the potential increases
with increasing number of subflows. This technique should be used after WC2 and WC3
61