# A Distributed Real-Time Monitoring Scheme for Air Pressure Stream Data Based on Kafka
## 4 Experimental Results and Analysis
### Comparison with Existing Work  
As shown in Table 6, to explore the performance of Kafka in the field of real-time monitoring, we compared our scheme with other real-time monitoring systems. By evaluating the technical approaches and performance data, we examined Kafka's performance and innovations in the real-time monitoring of air pressure. [PERSON] et al. [40] implemented an IoT-based airfield lightning system using an AMQP pub/sub broker. This system uses ActiveMQ to receive events from the airport lighting control and monitoring system to support monitoring functions and subscribes to ActiveMQ to receive commands from third-party clients. Tests showed that the system's delay in transmitting a single message is 15 ms. Similarly, [PERSON] et al. [41] studied the maximum sustainable throughput and delay of different pub/sub systems under realistic load conditions using traces from real sensors. The results indicated that for weather monitoring scenarios, RabbitMQ achieves a maximum throughput of 30k msg/s, with approximately 70% of the measured delay values being below 1 ms. These studies utilized AMQP based on the queue model, which may face performance limitations when handling large volumes of high-speed data streams. In contrast, Kafka, as a distributed message queue system, captures data streams from event sources in real time, enabling our scheme to achieve higher throughput and lower delays. [PERSON] et al. [42] designed a real-time intelligent environmental monitoring and analysis system framework based on underwater IoT and big data. This framework stores and analyzes data gathered from remotely operated vehicles and water parameter sensors on a multi-node Hadoop-cluster data-center platform. By utilizing Hive to handle larger data volumes, the framework can query one thousand records within 85 ms. [PERSON] et al. [43] developed the NEPTUNE system for real-time, high-throughput stream processing in IoT and sensor environments. This system is built on the Granules computing framework [46] and uses a pull-based method to ingest streams from IoT gateways. The stream processors then process the data and emit stream packets through one or more outgoing streams, achieving a throughput of 2000k msg/s with 93.7% bandwidth utilization. These systems transmit data through multiple steps, leading to a relatively complex processing flow. In comparison, our approach simplifies message processing by directly sending real-time data to Kafka producers, enabling faster data feedback. [PERSON] et al. [44] implemented the RT-DAP platform on Microsoft Azure for real-time data analysis in large-scale industrial process monitoring and control. This platform combines Kafka and Storm to process time series data in real time and feeds the results back to the physical system or into a database. Tests showed that the throughput of the platform was around 200,000 msg/s when the payload size was smaller than 64 bytes. In contrast, [PERSON] et al. [45] proposed an architecture for handling heterogeneous data sources in the IoT. By integrating multiple data sources using Kafka and employing a CEP engine to extract relevant events, they achieved a processing speed of 200k msg/s for data sizes of 320 bytes per record, with an average transmission delay of 25 ms per message. \begin{table}
\begin{tabular}{l c c c} \hline \hline
**Authors** & **Middleware** & **Throughput (msg/s)** & **Delay** \\ \hline [PERSON] et al. [40] & ActiveMQ & - & 15 ms (1 msg) \\ [PERSON] et al. [41] & RabbitMQ & 30k & 1 ms (1 msg) \\ [PERSON] et al. [42] & Hadoop & - & 85 ms (1k msg) \\ [PERSON] et al. [43] & Granules & 2000k & - \\ [PERSON] et al. [44] & Kafka & 200k & - \\ [PERSON] et al. [45] & Kafka & 200k & 2.5 ms (1 msg) \\ Proposed work & Kafka & 3000k & 15.6 (1k msg) \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Performance comparison of different systems. In comparison, our scheme formats the transmitted data into JSON and limits the size to 40 bytes, significantly enhancing system performance.