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

4.3 Cost-Based Vectorization
ALL). In fact, in the instance-based case, the costs of processing n messages are determined
by W (P ) = n · r · m, where r denotes the number of iteration loops for each message and
m denotes the number of operators in the iteration body. When rewriting the Iteration
operator to parallel flows, in the best case, the costs are reduced to W (P ) = n · m because
all iteration loops are executed in parallel. In contrast, due to the sub pipelining of a
vectorized plan, we can reduce the costs to W (P ′ ) = n · r + m − 1 + 2, where r denotes
the number of sub-messages. We see that costs of 2 must be added to represent the costs
for message splitting (Split) and merging (Setoperation). Furthermore, the optimality
of vectorized execution is given if r ≤ m.
Finally, note that this is a best-case consideration using an idealized static cost model
supposed for illustration purposes. This does not take into account a changed number of
operators during vectorization or additional costs for synchronization. However, in the
following sections, we will revisit these issues.
In conclusion, plan vectorization strongly increases the degree of parallelism and thus,
may lead to a higher CPU utilization. In this section, we introduced the basic vectorization
approach and the required meta model extensions. In addition, we described the core
rewriting algorithm as well as the specific rewriting rules that are necessary in order to
guarantee semantic correctness.
4.3 Cost-Based Vectorization
Plan vectorization rewrites an instance-based plan (one execution bucket per plan) into a
fully vectorized plan (one execution bucket per operator), which solves the P-PV. However,
the approach of full vectorization has two major drawbacks. First, the theoretical
performance and latency of a vectorized plan mainly depends on the performance of the
most time-consuming operator. The reason is that the work cycle of a whole data-flow
graph is given by the longest running operator because all queues after this operator are
empty, while queues in front of it reach their maximum constraint. Similar theoretical
observations have also been made for task scheduling in parallel computing environments
[Gra69], where Graham described bounds on the overall time influence of task timing
anomalies, which quantify the optimization potential vectorized plans still exhibit. Second,
the practical performance also strongly depends on the number of operators because
each operator requires a single thread. Depending on the concrete workload (runtime of
operators), a number of threads that is too high can also hurt performance due to (1) additional
thread monitoring and synchronization efforts as well as (2) cache displacement
because the different threads work on different intermediate result messages of a plan.
Figure 4.8 shows the results of a speedup experiment from Chapter 3, which was reexecuted
for two plans with m = 100 and m = 200 Delay operators, respectively. Then,
we varied the number of threads (k ∈ [1, m]) as well as the delay time in order to simulate
the waiting time of Invoke operators for external systems. Furthermore, we computed
the speedup by S p = W (P, 1)/W (P ′ , k). The theoretical maximum speedup is m/ ⌈m/k⌉.
As a result, we see that the empirical speedup increases, but decreases after a certain
maximum. There, the maximum speedup and the number of threads, where this maximum
speedup occurs depends on the waiting time, i.e., the higher the waiting time, the higher
the reachable speedup and the higher the number of threads, where this maximum occurs.
In conclusion, an enhanced vectorization approach is required that takes into account
the execution statistics of single operators. In this section, we introduce a generalization
99