## 6 Results and Discussions
### Simulation of the Monitoring and Control of Parking Lots in the North of a City
#### 6.2.6 Context III: Simulation of Parking Lots in the North of a City in Real Time  
This scenario and its parameterization were similar to that of Section 6.2.5, with the difference that the simulations were run activating the synchronization with real time. Thus, simulations were performed in a realistic way of the operation of the service, and the results and interactions with the cloud platform were analyzed. The details are presented in Table 15. Each of the experiments simulated a certain number of real hours of service operation. Figure 28 shows the total number of messages sent by simulator-1 and simulator-2. We can observe:  
Figure 27: A linear relationship between the total number of messages sent to the cloud platform by simulators and the number of simulated hours of service operation. (a) Simulator-1 sent 9.4597 messages per minute (0.158 messages per second); (b) Simulator-2 sent 4.9278 messages per minute (0.0821 messages per second). The total number of MQTT messages per second was 0.2401. 2.7 Model Performance of the Reservation Request Service and System's Recovery Time in Case of Failures  
The objective of this experiment was to estimate the limits of the system operations related to the simulations of the reservation requests. Additionally, we measured service recovery time when the service pod failed. Apache JMeter was the tool used to estimate the performance of the reservation request service. Apache JMeter helped us obtain performance metrics when we made multiple concurrent requests to the microservice deployed in the cloud platform. Requests generated by Apache JMeter arrive at the reservation request microservice that communicates with the reservation allocation service. The reservation allocation service was capable of providing the reservation number and stored the results in the database. The reservation microservices pod was deployed in the same VM where the primary replica of the database was deployed. Thus, we improved the response times of the service. Table 16 provides a summary of the metrics of the load tests performed with Apache JMeter. We ran the tests on a local computer that can only generate a limited total number of threads. The tests execute HTTP requests to the reservation request microservice that must \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline  & \multicolumn{4}{c}{**Simulator 1**} & \multicolumn{4}{c}{**Simulator 2**} \\  & \multicolumn{4}{c}{**Total Number of Sensors/Actuators = 1084**} & \multicolumn{4}{c}{**Total Number of Sensors/Actuators = 456**} \\
**Real** & **(P1; P2; P3; P4; P5; P6; P7; P8; P9; P10; P11; P12; P13; P14; P15)** & **(P16; P17; P18; P19; P20; P21; P22; P23; P24)** & **(P16; P17; P18; P19; P20; P21; P22; P23; P24)** & **(P14; Number of Messages of Messages of Messages of Messages of Messages of Messages of Time in the Simulator (min)** \\ \cline{2-7}  & **Arrivals** & **Departures** & **Total** & **Arrivals** & **Departures** & **Total** & **(min)** \\ \hline
1 & 303 & 47 & 350 & 63.98 & 152 & 20 & 172 & 62.57 \\
5 & 1489 & 763 & 2252 & 301.33 & 875 & 459 & 1334 & 301.23 \\
10 & 3082 & 2180 & 5262 & 605.06 & 1610 & 1164 & 2774 & 603.22 \\
15 & 4478 & 3601 & 8079 & 903.57 & 2359 & 1905 & 4264 & 902.19 \\
24 & 7079 & 6216 & 13,295 & 1443.97 & 3713 & 3262 & 6975 & 1442.54 \\ \hline \hline \end{tabular}
\end{table} 
Table 15: Real-time simulation of the operation of the parking lots in the north of Madrid. Figure 28: The relationship between the total number of messages sent to the cloud platform and the real time is linear. collect a reservation Id from the reservation assignment service. If approximately 1500 users make reservation requests for one minute, the system can respond to these requests with an average throughput of 7.8 clients/s. For example, that average throughput can broadly satisfy reservation requests with a rate of 20 requests/hour. Figure 29 shows the behavior of the reservation service when serving 2500 users with a 180-s ramp-up.