# Performance of Communication- and Computation-Intensive SaaS on the OpenStack Cloud
## 4 Results and Discussion
### Overhead of Cloud Infrastructure
The bandwidth of the native 1 Gbps Ethernet network measured using Iperf [52] was 941 Mbit/s. The virtualization of the Ethernet network reduced the network bandwidth by 2.8% of the bandwidth measured on the native hardware. Nearly the same results were observed on KVM-based VMs and Docker containers connected by the OpenStack network service Neutron. The Docker containers were connected to Neutron by Kuryr, but this did not significantly influence the network bandwidth. It is well known that the transfer of small messages is highly influenced by network latency. The increasing number of parallel processes leads to a larger number of messages of a smaller size for fixed-size problems. Thus, the latency of network communication becomes more important, especially for smaller-size problems. On average, the round-trip time on the native Ethernet network measured by the ping command was 17.9 us. For KVM-based VMs without and with OpenStack services, the round-trip time increased by 4.5 and 4.7 times, respectively. A lower increase in latency was measured on the virtual network connecting Docker containers. For Docker containers without and with OpenStack services, the round-trip time increased by 1.5 and 2.0 times, respectively. The results of benchmarks with MPI barriers were examined to determine how network virtualization influences communication time. The communication time increased by up to 2.4% and 2.2% of the benchmark time on the native hardware in the case of KVM-based VMs and Docker containers with OpenStack services, respectively. MPI communication between Docker containers was faster than that between KVM-based VMs connected by the virtual OpenStack network. However, the obtained difference was small because the communication-to-computation ratio was only up to 0.08 in the case of the GL1 benchmark on native hardware. In contrast, the wait time due to computational load imbalance increased by up to 8.2% and 8.6% of the benchmark time on the native hardware in the case of KVM-based VMs and Docker containers with OpenStack services, respectively. Thus, the increase in the wait time was significantly larger than that in the communication time. Moreover, the overhead on KVM-based VMs was smaller than that on Docker containers, which was relevant to the total execution overhead presented in Figure 9.  
Figure 10 shows the load imbalance measured on the native hardware and the OpenStack cloud in the case of the GL1 benchmark. The Native, Docker, KVM, ZunDocker, and NovaKVM columns represent the percentage imbalance, including wait times, obtained on the native hardware, Docker containers, KVM-based VMs, Docker containers with OpenStack services, and KVM-based VMs with OpenStack services, respectively. It is obvious that the percentage imbalance measured on the native hardware was the lowest. The percentage imbalance measured on Docker containers and KVM-based VMs without OpenStack services was only slightly higher. The observed differences can be treated as negligible because they do not exceed 0.9% and 0.5% in the cases of the Docker containers and KVM-based VMs, respectively. However, the percentage imbalance increased up to 13.8% and 12.5% on Docker containers and KVM-based VMs with OpenStack services, respectively. It is worth noting that the wait time of the process with the largest computational load and the longest computing time did not exceed 0.56% of the computing time on  
the native hardware, which was almost negligible (Figure 6). Times, when processes with average computational load waited for the process with the largest computational load to complete, were almost the same on the native hardware and the cloud. However, the wait times of the process with the largest computational load increased up to 9.1% and 8.5% on Docker containers and KVM with OpenStack services, respectively. This means that the process with the largest application load waited while other threads completed additional tasks of the cloud infrastructure.