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

4.6 Experimental Evaluation
allowed). For the cost-based vectorization, we used the introduced heuristic computation
approach with λ = 0, which changed the number of buckets (includes additional VMTM
operators) as follows: P 1 : from 10 to 8 buckets, P 2 : from 6 to 3 buckets, P 5 : from 9
to 6 buckets, and P 7 : from 18 to 3 buckets. Due to the absence of changing workload
characteristics, only the first invocation of the optimizer requires noteable optimization
time for merging buckets and flushing pipelines, while all subsequent re-optimization steps
take much less optimization time. Figure 4.19(b) shows this optimization time. Clearly,
the plan P 7 required the highest optimization time but still takes less than a second, which
is negligible compared to the achieved total execution time reduction of over 40 min.
Second, scalability experiments have shown that the absolute improvement increases
with increasing data size but the relative improvement with increasing data size depends
on the used plan. There are plans with constant relative improvement (e.g., P 1 ) and plans,
where the relative improvement decreases with increasing data size (e.g., P 7 ). Further,
the relative improvement of both vectorization approaches increases with an increasing
number of executed plan instances until the point of full pipeline utilization is reached.
From thereon, the relative improvement stays constant.
In conclusion, we achieve performance improvements in the form of an increase of message
throughput. In addition, we observe that the absolute benefit increases with increasing
number of plan instances and with an increasing data size as well.
Performance and Throughput
In order to evaluate both vectorization approaches in more detail, we use a template plan
that can be extended to arbitrary numbers of operators. Essentially, we modeled a simple
sequence of six operators as shown in Figure 4.20.
External
System
s1
Inbound
Adapter
Receive (o1)
[service: s1, out: msg1]
External
System
s2
External
System
s3
File
Outbound
Adapter
File
Outbound
Adapter
Assign (o2)
[in: msg1, out: msg2]
Invoke (o3)
[service: s2, in: msg2, out: msg3]
Translation (o4)
[in: msg3, out: msg4]
Assign (o5)
[in: msg4, out: msg5]
Invoke (o6)
[service s3, in: msg5]
filename=
’store1/Test1.xml’
mapping=
’maporders.xsl’
filename=
’store2/Test2.xml’
repeated
pattern when
varying the
number of
operators m
Figure 4.20: Evaluated Example Plan P m
A message is received (Receive), prepared for a writing interaction (Assign), which
is then executed with the file outbound adapter (Invoke). Subsequently, the resulting
message (contains Orders and Orderlines) is modified by a Translation operator and
finally, the message is written to a specific directory (Assign, Invoke). We refer to this
as m = 5 because the Receive operator is removed during vectorization. When scaling
m up to m = 35, we simply copy the last five operators and reconfigure them as a chain
of m operators with direct data dependencies. All of the resulting Invoke operators refer
to different directories. We ran a series of five experiments (each repeated 20 times)
according to the already introduced scale factors. The results of these experiments are
shown in Figure 4.21.
121