I would love to see languages like OCaml, D, Nim benchmarked here as well. They sit sortof in between Go and Rust, where I don't have to deal with manual memory management but get enough expressiveness to write a nice Lambda.
AWS Lambda Cold Start Times
11–20 of 233 posts
Re: AWS Lambda Cold Start Times
#12Many organizations use Linux OS to run file servers, print servers, content delivery systems, global caching servers, data archives, VPN servers, etc. Surely, Windows and macOS are easy to use, but Linux distributions have become more classy and user-friendly over the years. Linux is also considered to be more secure than Windows and macOS and makes software deployment quite easy. There are certain Linux distros that support enterprise-related tasks, and for that, you can consider these options:
Blog link: https://webhostingprime.com/best-linux-os/
Re: AWS Lambda Cold Start Times
#13We run a few .net core lambdas and a few things that make a big difference for latency. 1. pre-jit the package, this reduces cold start times as the JIT doesn't need to run on most items. Still does later to optimize some items. 2 is sticking to the new .net json seralizer. The reference code uses both the new and old newtsonsoft package. The old package has higher memory allocations as it doesn't make use of the Spa…
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 ?
Re: AWS Lambda Cold Start Times
#14Surprised 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.
Re: AWS Lambda Cold Start Times
#15At 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 doesn't really work like you'd expect and isn't recommended, as it only helps a particular use-case. The reason is that AWS Lambda will only keep a single instance of your function alive. That means if two requests come in at the same time, you'd see a cold start on one of those invocations. Instead, you want to look at somethin…
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 better.
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.
Re: AWS Lambda Cold Start Times
#16Something I discovered recently, for my tiny Go Lambda functions it is basically always worth it to run them at least with 256mb of memory even if they don't need more than 128mb. This is because most of my functions run twice as fast at 256mb than they do at 128mb. Since lambda pricing is memory_limit times execution time, you get better performance for free.
Test your lambda functions in different configurations to see if the optimal setting is different than the minimal setting.
Re: AWS Lambda Cold Start Times
#17Surprised 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.
Agreed, especially when you can run Javascript without cold starts at all on Cloudflare Workers
Re: AWS Lambda Cold Start Times
#18Earlier quoted context omitted.
> To combat this we wrote a "runWarm" function that kept the API alive at all times. This doesn't really work like you'd expect and isn't recommended, as it only helps a particular use-case. The reason is that AWS Lambda will only keep a single instance of your function alive. That means if two requests come in at the same time, you'd see a cold start on one of those invocations. Instead, you want to look at somethin…
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…
...or a big latency budget? Slow start is fine for a sudden burst for a lot of use cases.
Re: AWS Lambda Cold Start Times
#19Cool article, but shouldn’t Amazon be providing this kind of info? Surely they have this data internally.
They don't want to provide it themselves because then they have to admit that the performance is abysmal. Instead they let random blogos provide this data so they can just sit back and say "you're doing it wrong."
Re: AWS Lambda Cold Start Times
#20Surprised 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.
OP should have tested Deno (https://github.com/denoland/deno) too along side Node. Alas...