## 7 Performance Evaluation and Discussion  
For mission-critical IoT systems, one of the most important factors is the performance of the system. These systems should meet the properties of real-time systems, and thus, the response time of these should be minimal enough to satisfy real-time constraints. We compared the proposed platform with two relevant state-of-the-art solutions. The first solution is purely designed for MC-IoT systems, whereas the second solution is more of a DIY platform claiming to be generic for most of the categories of IoT systems. To test the performance of the proposed system, we simulated these systems for 50 virtual users and investigated the average response time and throughput of the respective systems. For this, the open-source tool Blazemeter was used. We recorded sample cross-domain requests using Apache JMeter and imported them into Blazemeter, which in turn simulated the script for a set of virtual users. The test statistics were recorded and visualized in graphical form, as shown in Figure 10. Figure 10 illustrates the throughput of the proposed system in comparison with the two approaches. It is evident that for 50 users, the throughput was approximately 55 tasks per second on average. In other cases, the throughput was on average approximately 47 and 33, which is less than the proposed system by some margin. However, there were occasional spikes for the proposed system, which show that for specific requests, the throughput was better by an even greater margin. The response time over time was also recorded, as shown in Figure 10. Much like with the throughput, the response time for the proposed system was lower than the corresponding systems. Despite the aim of MAC on Time (MoT) being latency optimization, the average response time was marginally lower than MoT. The reason for this is that the proposed system uses a very lightweight microservice, which reduces the latency on the communication medium and thus results in an overall lower response time. From these results, we see that it does not entirely outperform the existing systems, but given the range of applications, it can be considered a much better architecture for MC-IoT applications. Figure 9: Microservice deployment interface. Another crucial factor is the reliability of the system, which is vital for MC-IoT applications. An engine health test was performed to find the condition of the engine. The engine refers to the occupancy rate of network I/O, Memory, CPU, and connections. These attributes forecast the reliability of the system. For mission-critical applications, the engine health is of vital importance, given its critical nature. An overloaded engine must be avoided, otherwise it can lead to an unsafe state in which the mission can fail on any of its crucial requirements. The result of the engine health test for the proposed system is shown in Figure 11. It is evident that the CPU always remained below 5% and the maximum network I/O took 8 KB/Sec, which is very low. Similarly, the main memory was occupied to 10% on average irrespective of the increase in the number of connections, which proves that the system is stable and can respond even if the load increases. The per-request statistics of the test are summarized in Table 6. We evaluated the performance against parameters like average response time, maximum response time, average latency, standard deviation, 90% Line, 99% Line, 99% Line, and 100% on average average response time. The results of the engine are shown in Figure 10.  
Figure 10: Performance evaluation of proposed system w.r.t to the state-of-the-art methods. average throughput, and error rate. These are standard benchmarking parameters of apache jMeter for evaluating the performance of the test. From the above simulation, it is proved that the proposed system is very reliable in terms of load and scalability which is crucial for any mission-critical planning system. Figure 11: Engine health analysis.