## 6 Experiment and Result
### Emergency Service  
The emergency service sends messages to the smartphones of paramedics when the health indicators of elderly people are in an abnormal state. The key metric obtained in the experiments is the average response time of the system to provide an emergency alert. In parallel, we maintain several workloads on the messaging subsystem to verify the effects on the delivery times of the alert messages. In this paper, two possible locations for alert managers were analyzed:  
1. Alert manager 1: Can be placed on the patient's smartphone as an additional lightweight module within the app that collects vital sign data;
2. Alert manager 2: Can be placed as a Spark app in the cloud computing environment. It is a streaming service that continuously and dynamically monitors the vital signs in near real time. These configurations were chosen to understand and explore two issues: (a) the impact of the alert manager location on its development and functionality and (b) whether a near-real-time rule engine is feasible in an IoT environment. The tests performed in this section used mainly the messaging subsystem in a controlled environment. Figure 20 shows the relevant components used in the tests:  
Figure 18: Average throughput of a 3-broker Kafka cluster subjected to a workload of 36,000 requests for 1 s (Test 15), 60 s (Test 18), 120 s (Test 21), and 180 s (Test 24). A simulator of multiple patient vital sign messages. It is a JMeter-K8s cluster that publishes messages to the EMQ cluster to create various types of workloads on the messaging subsystem. The data generated by the JMeter-K8s cluster only include data from patients in normal health;
2. A simulator of vital signs of a patient in critical condition. It is a Ptolemy simulator supported by a MacBook that sends the simulation data to the patient's real smartphone via Bluetooth. The simulator is capable of generating messages with normal conditions of the patient's vital signs and messages with abnormal conditions;
3. A real smartphone with an app that collects data from the simulator of vital signs with the topic \"vitalSingsTopic/s1\". This smartphone forwards the patient data to the EMQ cluster with the same topic \"vitalSingsTopic/s1\". Additionally, in case the alert manager 1 installed on this smartphone detects abnormal conditions in the patient's vital signs, it generates emergency messages to the EMQ cluster with the topic \"emergencyTopic\";
4. The messaging subsystem in the cloud computing environment consists of the EMQ cluster, MQTT-Kafka bridge, and the Kafka cluster;
5. A Spark application that was implemented as alert manager 2. It is a rules engine that uses near-real-time analytics processing based on Apache Spark. Additionally, in case this Spark application detects abnormal conditions in the patient's vital signs, this application sends emergency messages to the EMQ cluster with the topic \"emergencyTopic\";
6. A real smartphone belonging to medical personnel with an app that collects the emergency message from the EMQ cluster. The mobile app is an MQTT client subscribed to the topic \"emergencyTopic\". The routes for sending the emergency message to the paramedics due to the two possible locations of the alert manager are a-b and c-d (see Figure 20). Figure 19: The dashboard of the patient monitoring service. The tests were initially conducted with a single MQTT-Kafka bridge until scaled enough to study behavior with multiple MQTT-Kafka bridges. As the MQTT-Kafka bridge was set up as a custom application to route data from the EMQ cluster to the Kafka cluster, the scalability of the bridge generates duplicate messages. Therefore, the scalability of the bridge was accompanied by a division and distribution of the topic \"vitalSignsTopic\". The number of subtopics used is a function of the number of MQTT-Kafka bridges used. The JMeter test plan was set up to accommodate multiple topic publishing. On the other hand, this means that the elderly population should be divided according to the number of subtopics.