# Bot-Based Emergency Software Applications for Natural Disaster Situations
## 4 Experiments
### Bottlenecks and Performance Evaluation for Rimay  
In this section, we present the performance evaluation of the Rimay application as the number of users increases every 30 s. Each user is a thread in the application and consecutively executes 10 requests. We set an interval of time of 3 s between requests. Different users can send requests in parallel. In Table 2, we show results for an experiment with four time intervals of 30 s each. In the first time interval, we process requests of 100 users; in the second time interval, we  
Figure 12: Distributed deployment: Resource utilization reported by (**a**) MongoDB and (**b**) the workers for the task: “10—Tasks Completed by Emergency”. Figure 13: Network costs reported by the April application deployed on two processors. process requests of 200 users, and in the last time interval, we process requests of 600 users. In the second column of the table, we show the average response time in milliseconds (ms.) reported by each task. The average response time is computed as the average of the results obtained in each time interval. We also show the number of tasks processed per second (s.) and the execution time in seconds required to process all the requests injected in each time interval. As expected, as the number of simultaneous users increases, the response time increases due to requests accumulated. We also deploy the Rimay application on two processors as described in Figure 10. We use three cores for the workers and two cores for other components. Figure 14 shows Rimay's performance when running the \"Enrollment\" task with a distributed deployment. The \(x\)-axis shows the time advance in seconds. The \(y\)-axis shows the utilization of resources (CPU, memory, and disk). During the first 30 s, the application processes 100 requests from users. In the next 30 s, the system processes 300 requirements. In the last time interval, from \(x=60\) s, the system processes 600 requests. Figure 14a shows that the resource utilization reported by MongoDB is below 50%. On the other hand, in Figure 14b, we show that the CPU and memory utilization in the workers are similar. The memory utilization slightly increases in each time interval, and the CPU reports peaks close to 70%. Figure 14b presents down peaks, which are due to the execution of a new group of threads. For example, at the beginning of the second interval of 30 s, we change the configuration of the application from a group of 100 threads to a group of 300 threads. All the threads are executed in a time window of 30 s to avoid saturating the system with additional threads. This parameter is called the ramp-up period. Therefore, when a thread pool is started, \(T\) threads are running per second. In other words, in the first time interval, we use \(T=100\) threads to process the incoming requests. In the second time interval, we use \(T=300\) threads, and so on. Notice that in the second time interval, when the application processes 10 requests per second (300/30 s), the CPU become a critical resource. Therefore, this figure shows that the CPU tends to saturate in the Rimay application, reaching utilization levels of 90% of utilization. Others tasks report similar behavior. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Task** & **Avg. Time (ms.)** & **\# Tasks per s.** & **Exec. Time (s.)** \\ \hline \multirow{4}{*}{Enrollment} & & 2.72 & 132.28 \\  & & 2.94 & 204.33 \\  & & 3.03 & 276.49 \\  & & 3.09 & 348.68 \\ \hline \multirow{4}{*}{Create event} & & 1.89 & 94.99 \\  & & 2.1 & 143.2 \\  & & 2.2 & 191.24 \\  & & 2.25 & 239.28 \\ \hline \multirow{4}{*}{Send report} & & 3.85 & 109.03 \\  & & 4.23 & 165.29 \\  & & 4.42 & 221.4 \\  & & 4.52 & 278.4 \\ \hline \multirow{4}{*}{Help/Status} & & 1.63 & 36.9 \\  & & 2.22 & 45.05 \\  & & 2.64 & 53.07 \\  & & 2.95 & 61.09 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Single processor: Execution time reported by different tasks executed by the Rimay application.