## 6 Experiment and Result
### Monitoring Service
#### 6.3.2 Kafka Cluster Services  
For the analysis of the performance of the message production service of the Kafka cluster, the JMeter-K8s cluster was used to simulate the transfer of messages to the Kafka cluster. Additionally, a preliminary analysis of the scalability of the Kafka cluster was carried out using one and three brokers. The search for the maximum throughput of the Kafka cluster is beyond the scope of this paper. The Apache JMeter plan for testing these scenarios is an XML file whose configuration parameters are shown in Figure 16. The test plan was mainly configured with the IP address of the load balancers used to access the cluster, the topic \"vitalSignsTopic\", and the value of QoS. Furthermore, the messages sent to the Kafka cluster have a structure and size expected in the real world as we established in Section 6.1. A Kafka client can manage the Kafka cluster's quality of service through the \"acks\" value (0, 1, \(-\)1). This value of \"acks\" (0, 1, and \(-\)1) affects the level of degradation of the cluster's performance (none, medium, and strong) depending on the type of recognition of the producers' message. In the experiments, the default value of acks was used, which is 1, thus guaranteeing the distribution of messages and minimally affecting the performance of the Kafka cluster messaging service. Before the execution of the tests, it was necessary to define the topic \"vitalSignsTopic\" in the Kafka cluster to provide redundancy and scalability. Thus, for the tests with one broker, we created the topic \"vitalSignsTopic\" with three partitions and one replica. Additionally, for the tests with three brokers, we created the topic \"vitalSignsTopic\" with three partitions and three replicas. Table 5 shows the results of the experiments with various workloads of message production requests to the Kafka cluster with one and three brokers (see Supplementary Materials Spreadsheet S3). From the JMeter-K8s cluster, messages were sent to the Kafka cluster using certain ramp-ups to analyze the functional behavior  
Figure 17: Average throughput of a 3-broker EMQ cluster subjected to a workload of 36,000 requests for 1 s (Test 19), 60 s (Test 22), 120 s (Test 25), and 180 s (Test 28). of the Kafka cluster for various periods of operation. For example, in tests 22, 23, and 24, the Kafka cluster flexibly handled the increased workload variation during testing. The average throughputs in these tests were 99.36 requests/s, 148.73 requests/s, and 197.46 requests/s with average response times values of less than 210 ms. The highest service capacity was obtained with three brokers, which could be established by comparing Tests 1, 2, and 3 with Tests 13, 14, and 15. Our final objective for the e-health system was to use a Kafka cluster with three brokers, so we analyzed in more detail the experiments with this type of cluster. Figure 18 shows the variation in the average throughput for Tests 15, 18, 21, and 24 in which the same volumes of service requests were used. However, different ramp-up values were used to observe the effects of pressure reduction on the Kafka cluster. The results show that the Kafka cluster was able to respond to some tests with a response time of more than 2 s, as in the case of Test 15 (Avg. RT = 1624 ms, Max. RT = 13,578 ms), which is not valid for systems that require average times between 1000 ms and 2000 ms.  
Based on the conditions of the experiments with the three-broker Kafka cluster, Test 13 (Avg. RT = 669 ms, Max. RT = 5965 ms) provides an approximation of the average throughput and the adequate average response time for the acceptable operation of the system. In this paper, we established 18,000 requests/s (Test 13) as the reference value of the number of requests for production messages that can be sent to the Kafka cluster. The average throughput and the average response time with which the Kafka cluster handles 18,000 requests/s are 999.78 requests/s and 669 ms, respectively.