## 4 Results and Discussions
### The Performance of Big Data Processing  
It is important to analyze the performance of big data processing under various conditions. Performance metrics such as system latency, throughput, and concurrency were utilized in this study. [PERSON] et al. utilized system latency and throughput to evaluate the performance of big data technology under different operations [81], while [PERSON] et al. used concurrency to evaluate big data technology under multiple clients [82]. In our study, system latency is defined as the time needed by the proposed system to handle, process, and store the sensor data into database. Throughput is defined as total number of sensors data processed per second. The last metric is concurrency which is defined as the number of clients accessed simultaneously to the system. The experiments was conducted with different numbers of servers and the response time was collected for analysis. The Java program was developed as a simulator to generate sensor data and send the data to the big data processing servers. The server was installed with Apache Kafka, Apache Storm, and MongoDB. The threads was used by Java program to simulate multiple clients. The detailed specifications of client and server computer can be seen in Table 8. In addition, the approximate size of each simulated data is around 211 bytes which consists of the device ID, the date and time when the data is generated and the value of sensor data (temperature, humidity, accelerometer, and gyroscope).  
Figure 8a shows that as the amount of sensor data sent to the cloud server increased, the response time also increased. The number of clients also affected the response time, since more time was required for the proposed system to process and store sensor data sent by a larger number of clients simultaneously. However, taking advantage of scalability support by adding more servers can help achieve lower response time compared to a single server as shown in Figure 8b. Figure 8c,d show the system throughput with different numbers of clients. Better performance could be achieved by increasing the number of servers. Furthermore, Figure 8e,f compare the system latency and database size of MongoDB and CouchDB. In this test, we used a single client and sent different amounts of sensor data to the cloud server at the same time. The Java Program was implemented on the client-side to send the sensor data to the cloud server. MongoDB performed better than CouchDB when the amount of sensor data increased. In addition, MongoDB occupied a lower database size than CouchDB did.  
Figure 7: The IoT-based sensor system’s (**a**) network delay, and (**b**) CPU and memory usage.  
Figure 8: Performance evaluation in terms of latency with different numbers of clients (**a**) and servers (**b**); throughput with different numbers of clients (**c**) and servers (**d**); comparison between MongoDB and CouchDB databases in terms of latency (**e**); and database size (**f**).  
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & \multicolumn{2}{c}{**Server**} & **Client** \\ \hline \multirow{4}{*}{**Hardware**} & Processor & Core i7-4790 & Core i7-4790 \\  & CPU & 3.60 GHz \(\times\) 8 cores & 3.60 GHz \(\times\) 8 cores \\  & RAM & 16 GB & 16 GB \\  & HDD & SSD 128 GB & SSD 128 GB \\ \hline \multirow{4}{*}{**Software**} & OS & Ubuntu Server 14.04 & Windows 10 Pro 64-bit \\  & Node.js & 8.4.0 & - \\  & Express & 4.15.4 & - \\  & Socket.IO & 1.7.4 & - \\  & Apache Kafka & 0.8.2 & - \\  & Apache Storm & 0.9.3 & - \\  & MongoDB & 3.6.2 & - \\  & JDK & - & 1.8.0\_121 \\  & Eclipse & - & 4.6.3 \\  & HttpClient & - & 4.5.3 \\ \hline \hline \end{tabular}
\end{table}
Table 8: The detailed specifications of server and client computer.