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

3.3 Periodical Re-Optimization
riodical re-optimization, we cannot guarantee to find the globally optimal plan. However,
often good plans are produced by these heuristics. Essentially, we discuss the
criticalPathOptimization algorithm (A-CPO) as well as the heuristicPatternMatchingOptimization
algorithm (A-HPMO), which are both based on our standard A-PMO.
Critical Path Optimization
The application of our first heuristic, critical path optimization, promises optimization
time reduction but does not change the asymptotic worst-case time complexity of the
optimization algorithm. The critical path cp(P ) of the plan is determined in the form of
operator execution times [LZ05]. We then apply the A-PMO only for this critical path and
thus we might reduce the number of operators evaluated by the optimization algorithm
from m to m ′ , where m ′ denotes the number of operators included in the critical path
with m ′ = |o i ∈ cp(P )| and m ′ ≤ m.
The intuition of this heuristic is that the execution time of a plan instance does not
depend on parallel subflows, which execution time is subsumed by more time-consuming
subflows. As a result, we only benefit from this heuristic if the plan includes a Fork
operator. This heuristic exploits the control-flow semantics of our flow meta model. In
the following, we illustrate the concept of critical path optimization with an example.
Example 3.5 (Critical Path Optimization). Recall the plan P 3 ′ from Example 3.2. Clearly,
the critical path of a plan can only be different to this plan if and only if parallel subflows
(Fork operator) exist. Then, we determine the most time-consuming subflow of each Fork
operator as part of the critical path, while all other subflows are subsumed and hence,
are marked as not to be optimized. Figure 3.8 illustrates the determined critical path of
the running example P 3 , where (o 3 ) is subsumed by (o 2 , o 5 ). Hence, we have reduced the
number of operators that are included in the optimization.
Assign (o1)
[out: msg1]
[5ms]
Assign (o1)
[out: msg1]
[5ms]
Fork (o-1)
Fork (o-1)
[60ms]
Invoke (o2)
[service s4, in: msg1, out: msg2]
[35ms]
Groupby (o5)
[in: msg2, out: msg4]
[26ms]
Invoke (o3)
[service s5, in: msg1, out: msg3]
[60ms]
Invoke (o2)
[service s4, in: msg1, out: msg2]
[35ms]
Groupby (o5)
[in: msg2, out: msg4]
Join (o4)
[in: msg4,msg3, out: msg5]
[10.01ms]
Join (o4)
[in: msg4,msg3, out: msg5]
[10.01ms]
Assign (o6)
[in: msg5, out: msg1]
[5ms]
Assign (o6)
[in: msg5, out: msg1]
[5ms]
Invoke (o7)
[service s5, in: msg1]
[40ms]
Invoke (o7)
[service s5, in: msg1]
[40ms]
(a) Plan P ′ 3
(b) Plan cp(P ′ 3)
Figure 3.8: Example Critical Path Optimization
This algorithm is a heuristic because we cannot guarantee to find the globally optimal
plan for two reasons. First, the critical path might change during the optimization. As
a consequence of not considering certain operators of the new critical path, we might get
suboptimal plans. Second, we do not consider data-flow-oriented operators not included
51