41–50 of 291 posts
I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS
Most of the time in Lambda is usually spent waiting for IO, which is slow in any language. If you’re using Lambda for heavy computation, that’s not a great choice.
I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS
On the one hand I read that JS Lambdas were often already under 100ms (30-50ms) On the other hand I heard legends about under 10ms Rust Lambdas.
66$ for running a AWS Lambda with 128 for a year seems very expensive.
Earlier quoted context omitted.
If a process takes that long, lambda would be a poor architectural choice.
Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
Earlier quoted context omitted.
It's still measured by wall clock time - not CPU time. I'd love to see them bill for actual CPU time.
I'd bet a significant portion of their margins come from this, given Lambda's focus on I/O-bound workloads.
Maybe even accounting for strong and weak nuclear forces (not sarcasm...we are engineering at the quantum level now, soon it will be apart of a business metric. Instead of 'equipment' being servers, it might be the domain-space-time used).
Earlier quoted context omitted.
If it takes 60 seconds, that's 600 steps. 601 steps isn't that much of a saving. It matters close to 0.
If a process takes that long, lambda would be a poor architectural choice.
Earlier quoted context omitted.
If a process takes that long, lambda would be a poor architectural choice.
Not necessarily. For low frequency workloads with reasonably long step times, Lambda can still make sense. (E.g. When videos appear in this S3 bucket, process them.) You might only drop videos in once a week, but when you do you want to run some code against them. There are plenty of distributed workflow reasons to run long running Lambdas infrequently rather than spinning up and down an EC2 instance.
I am curious to see if this will mean a shift to more efficient languages (Go or Rust) for Lambda services, as usually people default to JS
1. Python & JS 2. Go 3. C# & Java
I couldn't find any data on Rust.
The understanding at the time was that Python & JS runtimes are built-in, so the interpreter is "already running" Go is the fastest of compiled languages, but just can't beat the built-in runtimes. C# and Java were poorest as they're spinning up a larger runtime that's more optimized for long-running throughput.
https://docs.aws.amazon.com/lambda/latest/dg/best-practices....
https://medium.com/the-theam-journey/benchmarking-aws-lambda...
https://epsagon.com/development/aws-lambda-programming-langu...
https://read.acloud.guru/comparing-aws-lambda-performance-of...
Of course, benchmarks like this only go so far. Use as a starting point for your own evaluation; not as an end-all-be-all.
Anyone know why there's a hard limit of 15 minutes for Lambda (and 9 minutes for Google Cloud Functions)? Still seems really weird to me.
Chris Munns - Lead of Dev Advocacy for Serverless@AWS
66$ for running a AWS Lambda with 128 for a year seems very expensive.