# Simulating and Evaluating a Real-World ElasticSearch System Using the RECAP DES Simulator
## 5 Simulation Results
### Existing Opening.io Architecture: Response Time vs. Query Traffic  
In this section, we evaluate the performance of the Opening.io architecture by looking at the query response time while varying the query traffic (number of queries received by the system at the beginning of the simulation). The goal of this experiment was to determine the number of queries per second the system can handle.  
We monitored the query response time while varying the number of queries/requests per second received by the system. Note that we use the terms queries and requests interchangeably. Figure 3 represents a box plot (min, max, lower quartile, upper quartile) that shows the query response time based on the number of queries the system receives. Note that the prominent black dots in the figures show outliers of simulation results.  
The query response time increased gradually with the query traffic. The query response times for the blue and green queries took less than a second to run up to 140 requests (Reqs); i.e., 46 Reqs for each type. The response time for the red queries began to exceed the one-second threshold (the barrier represented by the red dotted line in Figure 3) for running the 140 Reqs traffic. Below this threshold, the system was capable of handling 140 Reqs with no requests impacting those arriving in the following seconds. Beyond that threshold, the execution of requests arriving at a time \(t\) would impact the response time of those arriving at time \(t+1\), thus creating a snowball effect on the response time.  
Figure 3(a) shows the performance degradation slope within a 10 second time interval for the query traffic of 140 Reqs/s. The goal of this experiment was to show that the increase in query response time for the traffic of 140 Reqs/s was slow. For the first second,  
\begin{table}
\begin{tabular}{l c c} \hline \hline
**Query Name** & **Targeted Data Node** & **Mean Service Time (ms)** \\ \hline Red-query & Data node 1 & 21 \\ Blue-query & Data node 2 & 17 \\ Green-query & Data node 3 & 19 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Characteristics of the queries used.  
Figure 3: Query response time achieved with different query traffic volumes. The red dotted line represents the threshold (barrier) of \(1\) second beyond which queries affect the response time of those received in the following second.  
only one type of query (i.e., red) exceeded the one second barrier. As time progressed, the other types of queries were also affected and took more time to finish. For example, we can see that the green queries took longer than one second to finish by 2 seconds. The response time of the blue queries increased slowly with time and did not exceed one second until the ninth second. This means that the traffic of 140 Reqs/s was the load at which the system began to slow down but with a moderate slope.  
Figure 3(b) shows that as we increased the query traffic to 150 Reqs/s, the query response time increased faster. This was due to the fact that the system was more stressed and slowed down more quickly.  
Figure 3(c) shows that the query response time increased even faster as we increased the query traffic to 180 Reqs/s. This is explained by the fact that we were approaching the saturation point. In fact, all three queries exceeded a one-second execution time from the first second. All the queries in the system were delayed due to the waiting time.