## 6 Experiment and Result
### Emergency Service
\begin{table}
\begin{tabular}{c c c c c c c c c c c c c c c c} \hline \hline  & & & & & & & & & & & & & & & & & & & \\ Number & Simulation & & & & & & & & & & & & & & & & & & \\ \cline{3-14} \multirow{-2}{*}{Number} & Simulation & & & & & & & & & & & & & & & & & & & & \\ \cline{3-14}  & Simulation & & & & & & & & & & & & & & & & & & & \\ \cline{3-14}  & Simulation & & & & & & & & & & & & & & & & & & & \\ \cline{3-14}  & Simulation & & & & & & & & & & & & & & & & & & \\ \cline{3-14}  & Simulation & & & & & & & & & & & & & & & & & & \\ \cline{3-14}  & Simulation & & & & & & & & & & & & & & & & & \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Information on the test environment and results of the measurement on the average response time to notify an emergency. For this sample, the response time of the system to produce the emergency alert could be calculated as follows:  
* 20:41:55.607000000 = 2.962 s;
* 20:41:55.607000000 = 3.986 s.  
The average system response time to communicate an emergency in each test was evaluated as the average of the response times to produce the alert of the 10 samples generated in the Ptolemy simulator. The results in Table 6 show the impact of various workloads and the increase in the number of MQTT-Kafka bridges. For example, Test 15 indicates that the workload could be supported using four bridges, obtaining the following results:  
1. An average system response time and a standard deviation of 2.3016 s and 0.503399378 s using alert manager 1, respectively;
2. An average system response time and a standard deviation of 2.9726 s and 0.7731912519 s using alert manager 2, respectively. The average system response time using alert manager 2 was mainly affected by the scalability of the MQTT-Kafka bridge. We observed that if we did not increase the number of MQTT-Kafka bridges when the workload on the messaging subsystem increased, the following occurred:  
1. The average system response time increased (Test 10 and Test 18);
2. The messaging subsystem service completely stopped the data flow toward Kafka (Test 6) due to bridge failure;  
Figure 21: Smartphone log extracts show: (**a**) the vital sign data collected by the patient’s smartphone at home. (**b**) The emergency message generated by alert manager 1 and received by the paramedic’s smartphone (**c**) The emergency message generated by alert manager 2 and received by the paramedic’s smartphone. 3. The messaging subsystem service partially stopped the data flow toward Kafka due to the failure of some bridges (Tests 10, 14, and 18) with loss of messages (% lost of Test 18 = ([60,000 \(-\) 40,068]/60,000] \(\times\) 100 = 33%). Although the bridge was scaled on a single and exclusive node to avoid affecting the capacity of the other components, the bridge scaled weakly compared to, for example, the MQTT cluster. This weakness is because our MQTT-Kafka bridge was built as a custom application to route data from the EMQ cluster to the Kafka cluster. Additionally, the bridge had to contend with the limits of the resources on the VM on which it was deployed. From Table 6, we can assert that the best option to carry out alert notifications is the use of alert manager 1. The use of alert manager 1 does not require the MQTT-Kafka bridge, and the response times of the system are shorter. However, using alert manager 2 can have other benefits. We can deploy the alert manager as a Spark app in the cloud computing infrastructure for individual or group analysis of data in near real time. Additionally, the management of the update and installation of alert manager software on the smartphones of all patients is not very flexible. However, the management of the alert manager software as a Spark app in the cloud computing infrastructure facilitates the management of the code, as it is a single point of update and use of the software. Finally, in the future we will implement the MQTT-Kafka bridge with new design strategies to scale more flexibly.