## 4 Evaluation
### Experimental Results  
Figure 2 shows the performance evaluation results of running a single container with \"Baseline\" and \"Adaptive\" (as described in Section 4.1) for Hadoop and Spark, respectively. As we can see from the results, the overall execution times increased in the Adaptive approach. For the K-means benchmark, the execution time increased by only 3% compared to the optimal result (Baseline) when using the Hadoop resulting in the lowest variation (as seen from Figure 2a). However, in the case of PageRank benchmark in Spark, the execution time increased by almost 50% with the largest variation, as depicted in Figure 2b. The main reason for high job execution time variance is potentially due to the difference in time-specific resource usage patterns of each Big Data workload, and the lack of initially assigned computing resources in the Adaptive approach. The initial resources of a single container in the Adaptive approach are allocated to use only one vCPU and 2.5 GB of memory, which can result in a potential bottleneck in the job execution, especially when it requires larger amounts of initial computing resources until the Adaptive can meet those requirements. Since our adaptive resource allocation scheme is based on a kind of hill-climbing algorithm that increases resource allocation values continuously until it achieves a peak solution, in the case of the single container experiment, our Adaptive approach was not fast enough to meet the initial resource requirements for some Big Data \begin{table}
\begin{tabular}{c c} \hline CPU & Intel(R) Xeon(R) Silver 4208 (8C 16T/2.10 GHz) \\ Memory & 32 GB \\ Storage & 500 GB SSD, 4 TB HDD \\ Operating System & CentOS 7.8 \\ Hadoop & Apache Hadoop 2.9.2 \\ Spark & Apache Spark 2.2.3 \\ Docker & Docker Engine 19.03.11 \\ HiBench & HiBench 7.0 \\ \hline \end{tabular}
\end{table} 
Table 3: Testbed H/W and S/W configurations. workloads. To summarize, an average of 18.7% of overhead can occur when the overall system is idle with our proposed scheme due to its scaling-up mechanism, which can be further studied in the future. Figure 3 shows the performance evaluation results of parallel executions of four different containers with \"Fair\" and \"Adaptive\" (as described in Section 4.1) for Hadoop (in Figure 2(a)) and Spark (in Figure 2(b)), respectively. Although execution times in the Adaptive approach increased for some benchmarks (e.g., for the Terasort and Join benchmarks using Hadoop in Figure 2(a), 25% of increase and 10% of increase, respectively), overall, our proposed scheme shows very competitive performance compared to that of Fair in terms of makespan. For example, in the K-means benchmark, the Adaptive scheme dramatically improves the makespan compared to that of Fair by 56% and 12% in Hadoop and Spark, respectively. This is because unlike the Fair approach where available computing resources are statically and equally assigned, our adaptive resource allocation scheme can effectively utilize idle computing resources during the course of job executions. Figures 4 and 5 show the resource utilization patterns of the \"Fair\" and \"Adaptive\" approaches in terms of main memory usages. As we can see from the results, the Fair approach cannot utilize available resources whenever a job is completed, which results in a waste of allocated computing resources and increased makespan even compared to the \"Baseline\". On the other hand, our proposed Adaptive approach can effectively leverage idle computing resources during the course of job executions, which can result  
Figure 3: Experimental results of concurrent container executions that can show the aggregated throughput improvements of our proposed approach. Figure 2: Experimental results of single-container executions that can show the overheads of our proposed approach compared to the best performance in the given computing environment.