i read that they offer C as well. wonder what those times look like
It's low (100-200ms). Read my post above
AWS Lambda Cold Start Times
141–150 of 233 posts
Re: AWS Lambda Cold Start Times
#142The 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…
So effectively you're going to pay double?
You increase the usage of the lambda, sure, but not by double unless all this lambda does is respond to the search. There's a point where this is all semantics when running cloud services with regard to how you've deployed your code behind gateways and lambdas, but most applications have obvious triggers that could warm up a lambda at 10% or less overhead.
And even then....lambdas are dirt cheap.
Re: AWS Lambda Cold Start Times
#143Any experience with Cloudflare workers? They are supposed to have 0 cold start time: https://blog.cloudflare.com/eliminating-cold-starts-with-clo...
Re: AWS Lambda Cold Start Times
#144Earlier quoted context omitted.
There is actually a really awesome middle-ground that AWS offers that no one seems to talk about. That is using ECS + Fargate. This gives you (IMHO) the best of both worlds between Lambda and EC2. ECS is Elastic Container Service. Think docker/podman containers. You can even pull from Dockerhub or ECR (Elastic Container Registry - amazon's version of dockerhub). ECS can then deploy to either a traditional EC2 compute…
>It has automatic scaling, so it can scale up and down with traffic (all of which is configured in ECS) Doesn't scaling take time, though? Doesn't downloading a new docker container definition and starting it take at least as long as initializing a new lambda function? Also with lambda there's no configuring to do for scaling. If anything lambda gives you tools to limit the concurrency.
Scaling does take time, but you would normally scale based on resource utilization (like if CPU or RAM usage exceeded 70%). So unless you had a really large and abrupt spike in traffic, the new container would be up before it's actually needed.
It's definitely not apples to apples with Lambda though--if you do have a very bursty workload, the cold start would be slower with Fargate, and you'd probably drop some requests too while scaling up.
If your app allows for it, a pattern I like is Fargate for the main server with a Lambda failover. That way you avoid cold starts with normal traffic patterns, and can also absorb a big spike if needed.
Re: AWS Lambda Cold Start Times
#145My 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…
I like Azure in general, but Function cold start times are really awful.
I regularly see start up times exceeding 10s for small, dotnet based functions. One is an auth endpoint for a self-hosted Docker registry, and the Docker CLI often times out when logging in if there is a cold start. I'm planning on moving these functions to Docker containers hosted in a VM.
I have other issues with Functions too. If you enable client certificates, the portal UI becomes pretty useless, with lots of stuff inaccessible. I have one such endpoint in production just now, and it's even worse than that, as every now and then it just... stops working until I manually restart it. Nothing useful in the logs either.
Re: AWS Lambda Cold Start Times
#146Re: AWS Lambda Cold Start Times
#147Re: AWS Lambda Cold Start Times
#148I was surprised by the quality of this one. That said...
Cold starts are a FaaS learning subject but they almost never matter much in practice. What workloads are intermittent and also need extremely low latencies? Usually when I see people worrying about this it is because they have architected their system with call chains and the use case, if it really matters, can be re-architected so that the query result is pre prepared. This is much like search results... Search engines certainly don't process the entire web to service your queries. Instead, they pre-calculate the result for each query and update those results as content CRUD happens.
Re: AWS Lambda Cold Start Times
#149Earlier quoted context omitted.
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?
That, and longer, were very common before they fixed ENI->VPC. Not everyone needs a Lambda to connect through the VPC, but it's reasonably common.
Re: AWS Lambda Cold Start Times
#150Earlier quoted context omitted.
Yes it does
You could make a fortune selling that by itself, unless your ops cost is just yolo provisioning and never doing backups/patching/etc.
I'll never understand how we got to this point of learned helplessness where people think hosted services like Lambda are the only ones capable of being secure and robust. It's madness..