# Performance of Communication- and Computation-Intensive SaaS on the OpenStack Cloud
## 4 Results and Discussion
### Overhead of Cloud Infrastructure  
The overhead of the cloud infrastructure can be important for the performance of any communication- and computation-intensive SaaS. In this study, the percentage difference in the execution time or the overhead was computed as  
\[O_{cloud}=\left(\frac{t_{cloud}-t_{native}}{t_{native}}\right)\cdot 100\%, \tag{3}\]  
where \(t_{cloud}\) is the SaaS execution time measured on the cloud infrastructure and \(t_{native}\) is the SaaS execution time attained on the native hardware. Figure 9 presents the percentage difference in execution time between Docker containers without OpenStack services (Docker), KVM-based VMs without OpenStack services (KVM), Docker containers with OpenStack services (ZunDocker), KVM-based VMs with OpenStack services (NovaDocker), and the native hardware. Figure 9 shows the overhead in computing time without waiting and communication, while Figure 9 presents the overhead in the total execution time of the GL1 benchmark. The difference in computing time (Figure 9), representing the overhead of computer hardware virtualization increased up to 1.2% and 0.5% of the computing time on the native hardware in the case of Docker containers and KVM-based VMs without OpenStack services, respectively. The performance overhead of the Docker containers was consistent with previous results [24; 25; 32]. The observed overhead of KVM-based VMs was even smaller than that measured in related works [19; 22; 23; 24; 25]. However, the obtained difference was rather small, while the highest values of the standard deviation were of the same order (up to 0.3%). The overhead in terms of computing time on KVM-based VMs with OpenStack services was larger than that on KVM-based VMs without OpenStack services by only 1.4% of the computing time on the native hardware. For Docker containers with OpenStack services, this difference increased from 1.7% to 2.6% of the computing time on the native hardware. It is worth noting that processes of the OpenStack infrastructure for the Docker containers had more influence on the overhead in terms of computing time than those of the OpenStack infrastructure for KVM-based VMs. The total execution overhead (Figure 9), measured on Docker containers and KVM-based VMs without OpenStack services, grew, increasing the number of parallel processes, in contrast to the overhead in computing time (Figure 9). The overhead due to virtualization of the network interface card was evaluated by examining the difference in the total execution overhead (Figure 9) and the overhead in computing time (Figure 9) on Docker containers and KVM-based VMs without OpenStack services. This difference was rather small and increased up to 1.2% and 1.8% for Docker containers and KVM-based VMs. Figure 9: Overhead of the cloud infrastructure in (**a**) computing time and (**b**) total execution time. However, a large increase in the overhead, increasing the number of parallel processes for the solution of the fixed-size problem, was observed in the cases of Docker containers and KVM-based VMs with OpenStack services. For Docker containers and KVM-based VMs on the OpenStack cloud, the overhead increased up to 13.7% and 11.2% of the execution time on the native hardware, respectively. On average, Nova with KVM-based VMs outperformed Zun with Docker containers by 2.5% of the execution time on the native hardware. Growth in the infrastructure overhead, increasing the number of processes used to solve the aortic valve problem by a parallel SaaS based on the finite volume method and commercial ANSYS Fluent software, was also observed for Docker containers of the OpenStack cloud [36]. The observed overhead values were less than 5% of the total execution time. However, the commercial software used as a black box did not allow extending the investigation and finding the reason for the observed overhead increase. The observed overhead of the cloud infrastructure can be caused by the virtual network overhead. Therefore, synthetic network benchmarks were performed.