- Newest
- Most votes
- Most comments
Hello.
- "There is a total of 120 seconds request timeout limit on the HTTP requests." Does this mean that from the time my app receives a request, it has no more than 120 seconds to complete a response?
Your application cannot take more than 120 seconds to return a response.
If a process takes longer than 120 seconds, it will time out and result in an error.
- "The request read and response timeout limit is contingent on the applications that you use. These applications may have their own internal timeouts, such as the HTTP server for Python, Gunicorn, has a 30 second default timeout limit. In such cases, the application's timeout limit overrides the App Runner 120 second timeout limit."...So if I configure my app to have a timeout longer than 120 seconds, does that override #1 above?
No, I don't think it can be longer than 120 seconds.
The explanation is that applications may have their own timeout settings, which may be shorter than 120 seconds.
In such cases, shorter timeouts apply.
- If the answer to #1 is "yes" and #2 is "no", why would I ever use AppRunner, when Lambda has a 900 second timeout? I'm developing an API to serve requests for subsets of a very large dataset. Because of the amount of data I want to serve, I figured AppRunner would be a better fit than lambda...but I guess not?
In the case of Lambda, there is something called cold start.
This may temporarily slow down API execution, but with AppRunner, the container is always running, so I think the delay will be less than with Lambda.
https://repost.aws/knowledge-center/lambda-cold-start
Also, since AppRunner is a container, I think it will be easier to migrate to another cloud if something goes wrong with AWS.
Relevant content
- asked 10 months ago
- asked 4 years ago
- asked 2 years ago
- asked 4 years ago
- AWS OFFICIALUpdated 5 months ago
