## 4 Research Methodology
### Performance Measurements  
The SmartSAT application was slightly modified to enable its deployment on each serverless platform. Nothing related to the application functionality was modified. Only the way that is used to load the database user credentials was modified. For the original Cloud Run service, the values were stored in the secret manager service and loaded from there. However, during the time of running the tests, these values were hard-coded. This was just to reduce the extra setup time required for the additional service configurations. Thus, all three platforms were tested with the database user credentials hard coded. This application was chosen for its ease of deployment, as it was already developed and containerized as part of the project [30], making it compatible with the selected services. To create a required load on the application, an Android emulator was used to simulate the GPS (Global Positioning System) movement of a bus along a selected bus route. The following steps were manually performed on each serverless platform (Cloud Run, App Runner, and Container Apps):  
* Navigate to the deployed service link from the Android emulator and log in to the website as a bus driver;
* Start two different bus routes. (This will emulate the same scenario when a real bus moves in that route);
* Access the application as a normal user (Bus Rider) from different devices;
* Click on a different bus stop icon so that the website shows the estimated arrival time for that stop. (a) Repeat this task for both the active routes from different tabs opened in the web browser. This will mimic multiple people accessing the application; (b) Once both buses reach their destination stops, stop the bus driving from the driver screen;
* Navigate to the cloud monitoring option in Google Cloud for the corresponding service and note the results. Traditionally, latency is measured as the time between a user's request and the response to that request. In a cloud environment, latency can be affected by factors such as user's network congestion on the client side and physical processing delays on the server side. Response time is similar to latency, but broadened to include not only latency but also server processing and queuing delays. A high latency typically relates to a high response time. For this study, we evaluated the performance of running the SmartSAT application on serverless platforms. As the application was deployed in a container, key metrics such as 'Container Request Latency', 'Container CPU Utilization', and 'API Response Time' were measured during the performance analysis of the application. Unlike the traditional latency, the 'Container Request Latency' in this measurement does not include user-side network congestion. The ranges of these metrics with a visual representation of their concepts are presented in Figure 1. A detailed description of the metrics is provided below:  
* _Container Request Latency (L)_: When a client (rider) sends a request to a server and waits for the corresponding response, the time it takes for this process is known as request latency. This is a crucial performance metric in the realm of computer networks and distributed systems. Factors such as distance between the client and server, network congestion, and hardware limitations can impact the latency. In this study, we conducted performance testing for three services from the same device and network. It is important to note that the latency values captured primarily reflect the container request latency and not the client-side network latency. Additionally, the cloud provider's network load can influence the service's response time to user requests. By maintaining consistent user-side network and hardware configurations, the latency measurements captured by the cloud provider's application monitoring services provide a clear picture of the application latency for the specific service.