# A Reliable Publish-Subscribe Mechanism for Internet of Things-Enabled Smart Greenhouses
## 4 Performance Evaluation
### Result
#### 4.3.1 Message Processing Time Evaluation Results with the Number of Messages and Message Size  
In this section, Figure 5 compares the message processing time through one second with the payload comprising four events depending on the number of messages delivered from the client in the greenhouse environment to the scalable and non-scalable brokers with the traditional and proposed mechanisms. Overall, what stands out from the data is that message processing time significantly improves approximately five-fold through all QoS categories for both scalable and non-scalable brokers, which means that our architecture enhances the protection of an IoT-equipped greenhouse system five times. Another noticeable point is that the Active MQ 5.15.8 scalable proposed broker takes on the most events coverage in the greenhouse environment across all QoS levels, whereas, in all QoS categories, another scalable proposed broker, EMQ X 4.0.8, has easily the lowest rates compared to non-scalable brokers.  
Looking at the details, as regards the original scalable1.4.15 and Beyywise MQTT Route 2.0 brokers, their message processing time is calculated at 80.04 and 82.0975, respectively, which means the original Mosquito broker covers 80.04 events and the original Beyywise MQTT Route 2.0 broker covers 82.0975 events in one second. By contrast, in our proposed method, the amount of information coverage for one second is 400.2 and 365.4875 in turn,  
Figure 5: A comparison of the message processing time (sec) of all scalable and non-scalable brokers in both original and proposed architectures across all the QoS categories.  
which makes all the events that happened in the greenhouse environment covered by the broker with our proposed topic classification.  
The improved message processing time in our architecture signifies the following:  
* Enhanced coverage and management of events, ensuring more events are processed promptly.
* Increased capability of the broker to manage a larger volume of concurrent events or messages.
* Improved responsiveness of the system to high event volumes, which is critical for real-time monitoring and control applications.  
Figures 6 and 7 demonstrate the number of messages in both the original and proposed scalable and non-scalable brokers at all QoS levels. When we look at the message size or data volume that is reduced in the proposed firmware, the number of messages grows dramatically compared to both types of traditional MQTT brokers. For instance, if the two processes of temperature rise and declining humidity in the greenhouse environment are investigated, these two processes with our proposed architecture of brokers have much less data volumes or relatively small message sizes, much greater number of messages in one second, and, even according to Figure 5, more events covered per second.Looking at the specifics, the proposed ActiveMQ 5.15.8 broker has a sharp increase in the number of messages across all QoS levels. Furthermore, there is a gradual rise in the proposed Mosquito 1.4.15 broker through QoS1 and 2 categories, while the results of the proposed Bevywise MQTT Route 2.0 broker have a considerable jump at the QoS1 level.  
Figure 6: The number of messages from non-scalable brokers in both original and proposed architectures across all QoS categories.