3 ms·
> To combat this we wrote a "runWarm" function that kept the API alive at all times. This sort of hack is not needed in AWS Lambdas, as they support provisione
by nuerow 5y ago
> To combat this we wrote a "runWarm" function that kept the API alive at all times.
This sort of hack is not needed in AWS Lambdas, as they support provisioned concurrency.
- davidjfelix 5y agoNor does it actually work. If you have a synthetic "runWarm" event, you'll trigger one concurrent lambda to stay warm. This helps if your cold start time is long and your average invoke time is short but you're just levying the cold start tax to the second concurrent user. There's no reasonable way to keep a concurrency > 1 warm with synthetic events without negatively impacting your cold start percentage for users. Provisioned concurrency is the correct solution and I'll remind everyone here that you can put provisioned concurrency in an autoscaling group, since the comments here seem to be saying keeping 100 lambdas warm is worse than a server that can handle 100 concurrent users (DUH!)