I would have liked to see more values along the lambda "breakpoints" between 1GB and 10GB of memory. Unless things have changed recently, my understanding is that CPU and IO scale up specifically at those breakpoints rather than being continuous.
AWS Lambda Cold Start Times
41–50 of 233 posts
Re: AWS Lambda Cold Start Times
#42Cool article, but shouldn’t Amazon be providing this kind of info? Surely they have this data internally.
They have never cared about this cold-start metric or the devs who do. The hope is that the first users have a degraded experience helps the next 1,000 users that minute have a perfect experience. To AWS it's like complaining about the end bit of crust in an endless loaf of sliced white bread that was baked in under 2 seconds.
This incorrect. They've made optimizations in this space, but it's a hard problem with a lot of variables. Examples include mostly solving for VPC + elastic interface provisioning, which used to take much longer and made Lambdas within VPCs unusable for customer facing APIs.
The size of the individual Lambda matters quite a bit. It has to be downloaded, processed, and initialized. Latency then varies by language. They can optimize things like their own Lambda runtime that executes that code on a per language basis being quicker, but the rest are hard problems and/or requires educating customers.
Their biggest problem is they oversold Lambda and serverless in my opinion, and now walk it back very slowly, buried deep in their documentation.
Re: AWS Lambda Cold Start Times
#43I'm surprised Node has cold-start issues. I had it in my mind that JS was Lambda's "native" language and wouldn't have cold start issues at all. Did it used to be like that? Didn't Lambda launch with only support for JS, and maybe a couple other languages that could compile to it?
Re: AWS Lambda Cold Start Times
#44It's really amazing to see how Lambda has grown to support all of these languages.
Re: AWS Lambda Cold Start Times
#45Surprised to see such mediocre performance from Node. It was an engineering decision on our team to develop one of our Lambdas with Node and we were deciding between Python and Node. Looks like Go and Rust look very promising.
I am not surprised that a re-purposed browser engine sucks for back-end.
The event driven architecture for NodeJS with simple requests like the test performed fits Node usage. I've seen past cold-start tests like this (admittingly it's been a while), and Node and Python are often the leaders of the pack with Java being the worst.
Re: AWS Lambda Cold Start Times
#46My 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…
My company is moving away from datacenter and into Azure and I have to get the az900 this week, it doesnt bode well.
And I was so happy to leave the clusterfuck of 300 aws lambda I was working with in my prev company.
What an expensive fad, and no engineer is ever consulted ...
Re: AWS Lambda Cold Start Times
#47I'm surprised Node has cold-start issues. I had it in my mind that JS was Lambda's "native" language and wouldn't have cold start issues at all. Did it used to be like that? Didn't Lambda launch with only support for JS, and maybe a couple other languages that could compile to it?
Yeah, at launch Lambda only supported Node.js.
https://web.archive.org/web/20141115183837/http://aws.amazon...
Re: AWS Lambda Cold Start Times
#48Earlier quoted context omitted.
Provisioned concurrency is insanely expensive. If you have any kind of a thundering herd access pattern then Lambda is a complete non-starter because of the warm-up and scaling characteristics. We eventually just put an nginx/openresty server on a regular medium EC2 instance and got rid of Lambda from our stack completely and now we're paying about 1/300th the cost we were previously and the performance is infinitely…
> I'm sure it has some use-cases in some kind of backoffice task queue scenario, but Lambda is nearly unusable in a web context unless you have a very trivial amount of traffic. This has been the outcome for me on several projects too. Just use loadbalanced EC2 (or EB, for simplification) and pay for a few instances running 24/7. It's actually cheaper than having a busy lambda in all my cases. The only other case (ot…
Yeah the caveats, gotchas, and workarounds you have to do to get something reasonable running on Lambda are just goofy.
At some point we just stopped and wondered why we were punishing ourselves with this stuff. We switched to a traditional webserver on regular EC2 instances and haven't looked back.
Re: AWS Lambda Cold Start Times
#49Slightly off topic, but what's the deal with Azure Functions cold start times in the Consumption (i.e. serverless) plan? I get cold start times in the multi seconds range (sometimes huge values, like 20s). Am I doing something wrong? Or is this expected?
Re: AWS Lambda Cold Start Times
#50I'm surprised Node has cold-start issues. I had it in my mind that JS was Lambda's "native" language and wouldn't have cold start issues at all. Did it used to be like that? Didn't Lambda launch with only support for JS, and maybe a couple other languages that could compile to it?
I thought nodejs/v8 or any javascript runtime would have some kind of startup cost since it has to parse and compile the javascript code first. See a simple hello world execution time comparison:
# a Go hello world
$ time ./hello
hi
real 0m0.002s
$ time echo 'console.log("hello")' | node -
hello
real 0m0.039s