# Bot-Based Emergency Software Applications for Natural Disaster Situations
## 4 Experiments
### Bottlenecks and Performance Evaluation for Ayni  
In this section, we evaluate the saturation points reported by different tasks executed in Ayni. To stress the app, we do not include the communication via the Telegram api because it limits the number of requests per second that we can send to the application to 30. In the following experiments, we send 600, 900, 1200, and 1500 requests to the application every 30 s. We deploy the application on a single processor according to Figure 9. We also show results of the Ayni application running on two processors according to Figure 10.  
In Table 1, we show the tasks executed by the Ayni application and the number of requests per second supported by each task before it fails. We show that there are two critical tasks: \"03--Create volunteers\" and \"06--Volunteer details\". Both tasks support a maximum of 60 requests per second on a single processor and 100 requests when the Ayni application is deployed on two processors. With more requests, the tasks became unstable, and some requests are not completed. Other tasks support a larger number of requests, as in the case of \"05--Task details\", \"07--Volunteers agree to participate\" and \"13--Volunteers accept tasks\". Figure 11 shows the requests processed successfully in a single processor (red line) and requests not completed (green line). We show the results obtained by the task \"10--Tasks Completed by Emergency\". The \(x\)-axis shows the advance of time in seconds. We divide the \(x\)-axis into segments of 30 s each. We start with 600 requests in the first time segment. Then, in the following segments, we increase by 300 the total number of requests. The results show that not all requests are completed in the fourth segment. That is, with an incoming rate of 40 requests per second (1200 request in 30 s), the system begins to saturate, and some requests are discarded. The system reports that 11.78% of the requests are not processed. Figure 10: Deployment of the applications on two processors. Figure 12 shows results obtained with a distributed deployment. In particular, we plot the utilization of different resources used by MongoDB (top) and the workers (bottom). Figure 12a shows that the CPU utilization reported by MongoDB reached peaks close to 60% in the last time interval. Similarly, Figure 12b shows the resource utilization reported by the workers. In this case, the CPU tends to be more demanding, reaching almost 100% of utilization in the last interval of time. On the other hand, the disk and memory utilization remains almost constant in both components (MongoDB and worker). Therefore, the CPU is the most critical resource for the Ayni application. We obtain a similar behavior with other tasks. Figure 13 shows the communication cost reported by each of the components deployed to run Ayni in a distributed manner. The \(x\)-axis shows the time advance and the \(y\)-axis shows the communication cost in bytes. The blue line represents the component worker (an Ayni instance), which reports the highest load on the network, followed by the Master (brown line) and in third place is MongoDB (light blue line). These results show how the communication rate tends to increase every 30 s. This is because every 30 s, the number of requests entered into the system increases. Notice that the peaks in red color and dark blue \begin{table}
\begin{tabular}{c c c} \hline \hline
**Task** & **\#Requests (Single)** & **\#Requests (Distributed)** \\ \hline
01 Create Emergency & 100 & 180 \\
02 Create Task & 200 & 360 \\
03 Create Volunteer & 60 & 100 \\
04 View Emergency Details & 400 & 770 \\
05 Task Details & 400 & 760 \\
06 Volunteer Details & 60 & 100 \\
07 Volunteers Agree to Participate & 400 & 750 \\
08 Tasks per Emergency & 400 & 750 \\
09 Active Tasks for Emergencies & 400 & 750 \\
10 Tasks Completed by Emergency & 200 & 380 \\
11 Volunteer Accepts Tasks & 400 & 770 \\
12 Volunteer Completes Tasks & 200 & 380 \\ \hline \hline \end{tabular}
\end{table}