# A Reliable Publish-Subscribe Mechanism for Internet of Things-Enabled Smart Greenhouses
## 4 Performance Evaluation
### Comparison with Existing Solutions
However, previous studies conducted by researchers [4; 27] have classified topics in a way that only supports a portion of the accessible data in the greenhouse. These classifications do not include all the events linked to various components, such as the connection status and the process of updating the server based on alterations made in the greenhouse. This section examines the benefits associated with the smallest message size within each level of a broadcast payload, in contrast to the findings provided in Table 4. The design we propose effectively mitigates the issue of data redundancy and minimizes data transmission, resulting in improved efficiency in broker processing time and reduced network congestion. Based on the aforementioned assessment, it can be concluded that the proposed pub-sub mechanism, which is deemed dependable, and the standardized MQTT-based SGP exhibit exceptional scalability and dependability. This is achieved via a straightforward design and minimal server processing requirements. Various MQTT optimization strategies assess their computational complexity and resource requirements by considering the number of topics, events, message size, and subscription throughput as seen in Table 5.  
The article [11] utilized seven distinct messaging and data communication protocols; it used one topic, four events, and a message size of 100 bytes, with a subscription throughput of 80-480 msgs/s. The single topic with 100 byte messages suggests higher processing and memory usage. The lower throughput compared to our method indicates less efficiency under high load. The article [47] used MQTT, with three topics, ten events, and a message size of 73 bytes; the subscription throughput was not specified. This setup has medium complexity with three topics, and the moderate message size reduces the resource load compared to the first article. Nevertheless, the absence of throughput data presents a challenge in evaluating efficacy under real-world conditions. The article [4] utilized MQTT, AMQP, and DSS, with three topics, two events, and a message size of 32 bytes, but the subscription throughput was not specified. Although this study defines three different topics, it fails to provide the same level of specificity and granularity as our approach, which encompasses nine topics. This discrepancy in the number of topics can affect the system's capacity to efficiently manage and categorize various categories of data, thereby influencing the overall performance and complexity. Our proposed approach employs both scalable and non-scalable MQTT brokers, with nine topics, four events, a message size of 20 bytes, and a subscription throughput of 677.388-1453.053 msgs/s. This approach has a lower complexity due to a hierarchical and dynamic topic management system, significantly reduced resource requirements due to smaller message size, and the highest throughput among the compared methods, indicating superior efficiency and scalability. Quantitative comparisons show that our method has the smallest message size (20 bytes), which leads to reduced computational load and memory usage, which is crucial for large \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Solution** & **Protocols** & **Number of Topics** & **Number of Events** & **Message Size** & **Subscription Throughput** \\  & & & & **(Bytes)** & **(msgs/s)** \\ \hline Our proposal & MQTT & 9 & 4 & 20 & 677.388–1453.053 \\ \hline \multirow{3}{*}{[11]} & Seven messaging and data communication protocols & 1 & 4 & 100 & 80–480 \\ \cline{1-1} \cline{2-6}  & MQTT & 3 & 10 & 73 & - \\ \hline \multirow{3}{*}{[4]} & MQTT, AMQP, DSS & 3 & 2 & 32 & - \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Quantitative comparison of MQTT optimization techniques. scale and high-frequency data environments like smart greenhouses. Regarding subscription throughput, our approach (677.388-1453.053 msgs/s) demonstrates the highest capacity, indicating that it can handle a significantly higher number of messages per second than the first article (80-480 msgs/s).