Users are complaining that your Cloud Run-hosted website responds too slowly during traffic spikes. You want to provide a better user experience during traffic peaks. What should you do?
A.
Read application configuration and static data from the database on application startup.
B.
Package application configuration and static data into the application image during build time.
C.
Perform as much work as possible in the background after the response has been returned to the user.
D.
Ensure that timeout exceptions and errors cause the Cloud Run instance to exit quickly so a replacement instance can be started.
Option C: Performing as much work as possible in the background after the response has been returned to the user, can be a valuable strategy to improve overall performance, but it might not directly address the initial latency issue that users experience during traffic spikes.
Here's a breakdown of why:
Initial Response Latency: Users primarily care about the time it takes to receive the initial response, not the time it takes to complete background tasks. While background processing can improve overall system efficiency, it won't reduce the perceived latency of the initial request.
Potential for Overloading: If too much work is deferred to the background, it could lead to resource contention and potentially degrade performance for subsequent requests.
While background processing can be beneficial for certain tasks, it's important to strike a balance between improving overall performance and addressing the initial latency concerns.
Option B, which involves pre-packaging configuration and static data into the application image, is a more direct and effective way to address the initial latency issue, as it reduces the cold start time and improves performance under load.
B. Package application configuration and static data into the application image during build time.
By packaging application configuration and static data into the application image during build time, the application can quickly serve requests without having to make additional requests to a database, thus reducing response time. Additionally, you might consider caching static data in the application to reduce latency and provide faster responses to user requests, also you could move some of the computation that is not time critical to be done asynchronously.
Option A "Read application configuration and static data from the database on application startup" will put more load on database during traffic spike, this will slow down the application's response time.
Option C "Perform as much work as possible in the background after the response has been returned to the user" could be a good approach, it allows the user to receive a response quickly, but the background work could take a long time and cause a delay in processing and might not be acceptable for certain use-cases.
Option D "Ensure that timeout exceptions and errors cause the Cloud Run instance to exit quickly so a replacement instance can be started" this is good practice and can help ensure that when an instance is having problems, it can be quickly replaced with a new one, but this will not improve the user experience during traffic peaks, but instead it will minimize the impact of a failed instance on the service's availability.
B is the answer from the recommendation of google because
"For starters, on Cloud Run, the size of your container image does not affect cold start or request processing time" so you can add the configuration and static data.
B is the answer.
https://cloud.google.com/blog/topics/developers-practitioners/3-ways-optimize-cloud-run-response-times
Instead of computing things upon startup, compute them lazily. The initialization of global variables always occurs during startup, which increases cold start time. Use lazy initialization for infrequently used objects to defer the time cost and decrease cold start times.
Not A - should store static data as global variables
Not B - the larger the image, could slow down the startup time
Not D - no errors were mentioned, app is only slowing down when traffic spikes
C - process in backgrounds
I disagree, the answer is B; with image caching the startup time won't change significantly. As for answer c, Cloud Run can't do any background work unless you use "always-on" cpu allocation, but that comes with a big increase in cost.
upvoted 2 times
...
...
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
thewalker
1 month agothewalker
1 month agopurushi
1 year, 3 months agoomermahgoub
1 year, 10 months agoomermahgoub
1 year, 10 months agotelp
1 year, 10 months agoTNT87
1 year, 11 months agozellck
1 year, 11 months agogardislan18
1 year, 11 months ago[Removed]
1 year, 11 months ago