## 5 Evaluation Results
### Results of Performance Analysis
#### 5.3.1 Results Analysis  
In terms of the 'Container Request Latency', Google's Cloud Run demonstrated a lower latency compared to AWS's App Runner. Cloud Run has latency, with an average request latency of 50 milliseconds (Figure 2). AWS App Runner has a higher latency, with an average request latency of 91 milliseconds (Figure 3). Azure Container Apps monitoring services do not have the ability to capture the container latency for the applications deployed. Due to this, the values for the Azure Container apps are not available. The total load on the cloud provider for a specific time can impact the performance of that provider. The 'total load on a cloud provider' refers to the capacity of the provider's entire infrastructure, not just the specific service we have built. If a cloud provider's physical resources in the region where our application is located are heavily utilized, this could negatively affect our application's overall performance. This is because increased network traffic can sometimes lead to slight performance degradation. The performance test for the Cloud Run service and the remaining two services were performed over two days. We cannot attribute any specific behavior from the Google Cloud as a key factor for better results on the latency value. Regarding the response time to distance matrix API, the average response time was better when the application was hosted on Cloud Run than being hosted on App Runner and Container Apps (Figure 4). The response time for Cloud Run is 63.7 milliseconds on average, while App Runner and Container Apps have an average response time of 71.38 and 66.8 milliseconds, respectively. Tests for AWS were run from 10:50 p.m. to 12:30 a.m. and for Azure from 11:30 a.m. to 12:30 p.m. Therefore, a single graph is presented to cover the results for both services during the test duration. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Performance Metrics** & **Google Cloud Run** & **AWS App Runner** & **Microsoft Azure Container Apps** \\ \hline Request Latency (Container) & 50 ms & 91 ms & - \\ Response Time (Distance Matrix API) & 63.7 ms & 71.38 ms & 66.8 ms \\ CPU Utilization & 23\% & 47\% & 0.000773\% 1 [FOOTNOTE:1]Footnote 1: [[https://github.com/google-cloud-run/](https://github.com/google-cloud-run/)]([https://github.com/google-cloud-run/](https://github.com/google-cloud-run/))
[ENDFOOTNOTE] \\ \hline \hline \end{tabular} Note: The corresponding graphs for each parameter can be found in Figures 2–7. 1 Azure App monitoring graph shows the values in millicores. Thus, this value is converted to a percentage using Formula (5).  
\end{table} 
Table 4: Comparison results on request latency, response time, and CPU utilization. As shown in Figure 4 and Table 4, the average values of A and B represent the response time for AWS App Runner, while the averages of C and D represent the response time for Azure Container Apps. We observe that the better API response time when hosted on Google Cloud Run may be because the distance matrix API was also from Google, which may have helped in faster communication between the application and API. This result may not be surprising because the services from the same provider might have an upper hand as the communications between these services might be faster as compared to a different service outside the provider. Figure 4: Response time for Google Cloud Run, AWS App Runner, and Azure Container Apps (A = 71.66, B = 71.11, C = 67.22, D = 66.38). Figure 3: Request latency for AWS App Runner. Figure 2: Request latency for Google Cloud Run. In terms of CPU utilization, Google Cloud Run uses an average of 23% (Figure 5). AWS App Runner uses the highest amount of CPU, with an average utilization of 47% (Figure 6). Azure Container Apps uses the lowest amount of CPU, with an average utilization of 0.000773% (Figure 7). Built-in monitoring tools automatically gathered data about CPU utilization based on the percentage of the allocated resources that were being used.