## 3 Investigation of Scalability and Impact of Virtualization on Performance of the System
### Results Analysis
#### 3.2.1 Influence of Server Core Number on Scalability  
In our tests load was simulated by increasing the number of clients-IoT devices. Selected load defined as the number of clients in a given test stems from the fact that we would like to assess characteristics from small load until system overload. Particular values start with the number of client nodes multiplied by 30, followed by multiplication by 40, 50 etc. Total number of clients correspond to the values considered in research works analyzed in Section 2. Experiments were repeated for various number of cores available on the server. It is expected that both numbers of requests handled by the server will increase and request-response times will decrease in the function of core count.  
Figures 2 and 3 present numbers of successfully processed requests by bare-metal and containerized environments respectively. Four continuous lines represent four different configurations used on the middleware side, as follows:  
* C0-1--2 CPU cores,
* C0-3--4 CPU cores,
* C0-19--20 CPU cores,
* C0-39--40 CPU cores (including HyperThreading).  
The dashed, vertical lines correspond to the points of optimal load introduced in Section 3.1.4. For a given optimal load point, the color of a vertical line is the same as the color of a plot which the given optimal point refers to. As we can see, for the configuration with 4 cores (C0-3) the optimal load is at 1450 devices, the 20 cores setup (C0-19) has the optimal load at 2030 devices and the most powerful configuration of 40 cores (C0-39) achieves the optimal load of 2320 devices. For configuration with 2 cores (C0-1) the system is overloaded and increasing the number of IoT devices results even in a slight drop of the number of successfully processed messages. It has no optimal load point in the measurements and as such is not analyzed further in terms of times. It is apparent that the system is scalable--a higher core count results in moving the optimum load point to the right side of the X axis and being able to serve more requests successfully during the test. This means that more cores involved in processing result in better availability of the service--more devices can be served in the same time frame. This also shows that the middleware platform benefits from a multicore environment.  
Figures 4 and 5 present request-response times measured on the client side for bare-metal and containerized cases. Based on the numbers of successfully processed requests we focused our attention on the configurations with respective optimal points for C0-3, C0-19 and C0-39 because loads above the optimal points correspond to the scenarios of significant drops in the number of successfully processed messages. The optimal load for a certain configuration (e.g., C0-3) is also handled by a larger configuration (such as C0-19 and C0-39). Bars represent median times while whiskers visualize first and third quartiles. We can see that processing times grow with a growing load for a given configuration. Moreover, we can see that processing time is significantly lower for configurations C0-19 and C0-39 versus C0-3. Comparing the configurations with 20 cores and 40 cores we can see that while median processing times are very close, C0-39 (obtained with the HT technology) has visibly narrower quartiles for the same number of devices and can serve efficiently one larger tested load i.e., that of 2320 devices instead of 2030 with the 20 core configuration.  
Figure 4: Processing time of request-response process from client side—bare-metal, bars denote medians and whiskers Q1 and Q3 quartiles.