If cold start times are an issue use Cloudflare workers instead, they’re always warm.
oh baby, they are warm indeed
AWS Lambda Cold Start Times
111–120 of 233 posts
Re: AWS Lambda Cold Start Times
#112Earlier quoted context omitted.
Great tip for running the JIT AOT, for anyone interested Microsoft calls this "ReadyToRun" compilation [1]. [1] https://docs.microsoft.com/en-us/dotnet/core/deploying/ready... I wonder did you test if the increased size results in an actual win for the startup time ?
The test code is quite small and might not benefit from R2R that much, libs it relies on are already jitted. Ditching Newtonsoft would affect response time though.
I have similar code where it takes some JSON input, and sends it off to SQS with a small bit of formatting. It impacts cold starts even for these smaller functions.
Re: AWS Lambda Cold Start Times
#113If anyone is running into cold start problems on Firebase, I recently discovered you can add .runWith({minInstances: 1}) to your cloud functions. It keeps 1 instance running at all times, and for the most part completely gets rid of cold starts. You have to pay a small cost each month (a few dollars), but its worth it on valuable functions that result in conversions, e.g. loading a Stripe checkout.
This is basically how Google Cloud Run works if I'm not mistaken.
And AWS Lambda "provisioned concurrency".
Re: AWS Lambda Cold Start Times
#114My experience with cold starts in Azure Functions Serverless is pretty awful. Like most other Azure services, their affordable consumer grade offerings are designed from the ground up not to be good enough for "serious" use. Cold start times compared to Lambda are worse, and in addition, we would get random 404s which do not appear in any logs; inspecting these 404s indicated they were emitted by nginx, leading me to…
Same experience with Firebase. I just joined a team that has been using it. I've never worked with serverless before, and it boggles my mind how anyone thought it would be a good idea. The cold starts are horrendous. In one case, it's consistently taking about 7 seconds to return ~10K of data. I investigated the actual runtime of the function and it completes in about 20ms, so the only real bottleneck is the fucking…
Not a fit for every scenario, but you can set a minimum number of instances for Firebase to keep ready. Should help reduce cold starts: https://firebase.google.com/docs/functions/tips#min
Re: AWS Lambda Cold Start Times
#115At my last job we built an entire API on top of serverless. One of the things we had to figure out was this cold start time. If a user were to hit an endpoint for the first time, it would take 2x as long as it normally would at first. To combat this we wrote a "runWarm" function that kept the API alive at all times. Sure kind of defeats the purpose of serverless but hey, enterprise software.
> 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.
Nor 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!)
Re: AWS Lambda Cold Start Times
#116My experience with cold starts in Azure Functions Serverless is pretty awful. Like most other Azure services, their affordable consumer grade offerings are designed from the ground up not to be good enough for "serious" use. Cold start times compared to Lambda are worse, and in addition, we would get random 404s which do not appear in any logs; inspecting these 404s indicated they were emitted by nginx, leading me to…
For the Azure Functions consumption plan this can be mitigated to an extent by just having a keep alive function run inside the same function app (set to say a 3-5 minute timer trigger).
Re: AWS Lambda Cold Start Times
#117The best cold starts are those which aren't noticed by the user. For my blog search (which runs on Lambda), I found a nice way of achieving that [1]: as soon as a user puts the focus to the input field for the search text, this will already submit a "ping" request to Lambda. Then, when they submit the actual query itself, they will hit the already running Lambda most of the times.
And, as others said, assigning more RAM to your Lambda than it actually may need itself, will also help with cold start times, as this increases the assigned CPU shares, too.
[1] https://www.morling.dev/blog/how-i-built-a-serverless-search...
Re: AWS Lambda Cold Start Times
#118Earlier quoted context omitted.
7s cold start is weird. I think there has to be more to the story than that.
I've seen 30s on AWS, so it's not that surprising. They have now improved it greatly though. And yet I still believe it's a great technology, as always it's a matter of putting it on the right use case. Message consumption from a queue or topic, low traffic and low criticality API are two great use cases.
30s is probably an edge case. Did this use Java/JVM runtime without AOT/GraalVM? I cannot imagine any other runtime that would cause 30s cold start. Care to share more details on this?
Re: AWS Lambda Cold Start Times
#119Earlier quoted context omitted.
Same experience with Firebase. I just joined a team that has been using it. I've never worked with serverless before, and it boggles my mind how anyone thought it would be a good idea. The cold starts are horrendous. In one case, it's consistently taking about 7 seconds to return ~10K of data. I investigated the actual runtime of the function and it completes in about 20ms, so the only real bottleneck is the fucking…
7s cold start is weird. I think there has to be more to the story than that.
Same intuition. We run ~all our back on firebase cloud functions since Beta in 2017 and cold start has never been such a problem.
Re: AWS Lambda Cold Start Times
#120Earlier quoted context omitted.
7s cold start is weird. I think there has to be more to the story than that.
I've seen 30s on AWS, so it's not that surprising. They have now improved it greatly though. And yet I still believe it's a great technology, as always it's a matter of putting it on the right use case. Message consumption from a queue or topic, low traffic and low criticality API are two great use cases.
[deleted]