# A Testbed to Evaluate the FIWARE-Based IoT Platform in the Domain of Precision Agriculture
## 5 Results
From the second perspective (requests served per second, see Figure 5c and Table 3):  
* The lowest rate of requests processed was 2.89 req/s with a payload of 1 MB. * The second worst result was 28.46 req/s at a payload of 100 kB. * The next result (252 req/s) at a payload of 10 kB is substantially better. * Finally, the measure of throughput obtained (978 req/s) in the simulation of a 1 kB payload is far superior to the other cases in the study. We would note that here the behaviour is exactly the opposite of the preceding case. The system performs better in terms of the number of requests and worse with regard to payload. To check whether a greater throughput number in terms of requests per second is possible, we ran a test with a minimum payload of 300 bytes. The results are similar to those in the case of a \(1\)kB payload. For that reason they are not shown here. No significant improvements were found below a payload of 1 kB. \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Region** & **1 kB** & **10 kB** & **100 kB** & **1 MB** \\ \hline Close to linear & [1.. 24] & [1.. 12] & [1.. 12] & [1.. 8] \\ Increase slow/fast & [24.. 72] & [12.. 24] & [12.. 24] & [8.. 20] \\ Degrading performance & [72.. & [24.. & [24.. & [20.. \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Number of active entities simulated in each type of test. \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Region** & **1 kB** & **10 kB** & **100 kB** & **1 MB** \\ \hline Close to linear & [25.. 712] & [157.. 1996] & [749.. 2437] & [760.. 2640] \\ Increase slow/fast & [712.. 978] & [1996.. 2520] & [2437.. 2846] & [2640.. 2963] \\ Degrading performance & [978.. & [2520.. & [2846.. & [2963.. \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Throughput obtained in kilobytes per second. \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Region** & **1 kB** & **10 kB** & **100 kB** & **1 MB** \\ \hline Close to linear & [25.. 712] & [15.7.. 199.6] & [7.49.. 24.37] & [0.76.. 2.64] \\ Increase slow/fast & [712.. 978] & [1996.. 252] & [24.37.. 28.46] & [2640.. 2.89] \\ Degrading performance & [978.. & [252.. & [28.46.. & [2.89.. \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Throughput obtained in requests served per second. Senarios that were densely populated with sensors such as the one discussed in Section 4.1 imply a high update rate. For this reason, a RESTful server that supports a high degree of concurrency and which can also process a large number of applications nearly in real time is required. The results described show that the best choice to get the most out of Orion in this type of scenario is a payload of between 1 kB and 10 kB. The final payload depends on the needs of each IoT application (estimated degree of concurrency or number of active entities, attribute domain, etc). An interesting scenario is to study the behaviour of FIWARE faced to blocking and non-blocking requests. Blocking requests are typical of intermediate nodes, especially the connection between the Generic Enablers IoT Broker and Context Broker (see Figure 3). Non-blocking requests are typical of sensors, or IoT final nodes, which for energy efficiency reasons can not be blocked waiting for a response from the server. Normally, a sensor sends an asynchronous request and closes the connection to save energy. This simulates the behaviour of a final IoT node which does not maintain the connection, when unnecessary in order to conserve energy. To simulate NGSI traffic generation from final IoT nodes, the non-blocking context generation method must be used so as to permit the generation of NGSI traffic in an asynchronous manner, with load peaks (bursts) that exceed the capacity of the Orion server. The purpose of this test is to measure maximum throughput in terms of requests served per second or kilobytes per second for both type of requests, blocking and non-blocking. The tests were performed with a payload of 1 kB, i.e., that which allowed simulation of the highest degree of concurrency with the blocking method.