# Virtual Replication of IoT Hubs in the Cloud:
## 4 Experimental Analysis
### Performance Evaluation
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Hub** & **Initialization** & **Res. Add** & **Sync Res. Group** & **Sync Single Res.** \\ \hline
[Local] Raspberry Pi CPU & 96\% & 17.45\% & 15.15\% & 6.93\% \\
[Local] Raspberry Pi Memory & +2.7\% & +0.02\% & +0.01\% & +0.002\% \\
[Remote] Azure VM Remote CPU & 97\% & NA & 34.22\% & 1.93\% \\
[Remote] Azure VM Memory & +1.9\% & NA & +0.01\% & +0.001\% \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Average CPU and Memory utilization percentages related to specific IoT Hub procedures on both local and remote instances. Figure 12: Effect of replica management with respect to the increasing number of requests per second on Microsoft Azure Infrastructure. is activated whenever the response time exceeds a threshold set to 800 ms. The graph clearly shows that the response time tends to increase linearly as a function of the rate of requests until the IoT Hub reaches a breaking point associated with the maximum number of requests it can handle. This is clearly visible in the areas of the graph characterized by steep slopes. When a slope is detected, we activate a new replica, which brings the response time back to a value that meets our operational requirements. As the request rate increases, new replicas are created. The average creation time of a IoT Hub replica is related to the maximum amount of resources generated by the nodes: once the number of resources reaches the processing limit of the IoT Hub, then a new replica is created. Therefore, if the number of nodes increases, this has anticipates the creation of a replica, but it does not influence the creation time. As shown in Figure 12, we stopped our experimentation after the activation of 3 replicas. It is worth noting that: (i) a new replica is activated almost periodically (every 800 ms, according to the set threshold) and (ii) the slope of the response time between two consecutive activations is inversely proportional to the number of active replicas. The definition and the widespread adoption of container-based technologies have significantly changed and re-designed the way Cloud and Fog applications can be deployed and delivered to final users. In order to provide a thorough performance evaluation of the proposed solution, we have also created a container-based version of the IoT Hub using the Docker platform [15]. The container has the same networking configuration, features, and services running on the VM-based version but shares the Operating System Kernel and features with other running container instances. The local experimentation has been conducted using a Virtual Machine running Ubuntu 14.04, with one 2.0 GHz processor and 1 GB RAM, on top of which Docker 1.11 has been executed with the aim of evaluating the startup time of the dockerized IoT Hub. This low-end hardware profile, compared to realistic data center facilities, has been purposely chosen to show the small footprint of the IoT Hub. In Figure 13, the average total startup time (dimension: [ms]) required to activate a fully operative IoT Hub instance, as well as the breakdown of container and IoT Hub services startup time, are shown. The presented results have been averaged on 1000 runs on the configured setup. The container startup time simply considers the activation of a Docker container instance. On top of this running instance, we measure the time required to activate all IoT Hub services and to respond to incoming HTTP and  
Figure 13: Average IoT Hub startup time (dimension: [ms]) on a Docker container. CoAP requests. The results show how a container-based approach can efficiently be adopted both on Cloud or Fog infrastructures (according to the target application scenarios) to support efficient and highly dynamic creation and management of IoT Hub replicas on top of existing host machines.