51–60 of 291 posts
I am impressed that computation is billed by the ms nowadays. I'm an ignorant in AWS Lambda but how do you know if their ms measurement is accurate? Is there any way to verify this?
- Chris - Serverless@AWS
For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.
Earlier quoted context omitted.
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.
That's the point- billed per ms, a Lambda that executes in 5ms is 10x cheaper than one that takes 50ms. Billed per 100ms interval, the total cost of the two is the same.
I'm not questioning that 5 is a tenth of 50. I'm questioning the Rust speed :D
Earlier quoted context omitted.
I've got bad experiences with go startup (i.e., cold runs). They're much more expensive than I would have expected. If node can indeed run in 40ms (as https://news.ycombinator.com/item?id=25267211 says), then I'm surely going back to JS.
What is your experience? Go is an AOT compiled language so the only thing I could imagine you running into on startup is loading the binary into memory? Theres not a cold-start issue with Go, as its not an optimizing JIT. Edit: Bizarre. Seems like Go on lambda does actually have slower cold start than JS or Python. I wonder if its just that the binary is likely larger than the equivalent JS source code? https://level…
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
- Chris, Serverless@AWS
For reference - Lambda functions used to billed at 100ms intervals. My Node.Js function usually only takes 37-40ms to run. So this is a pretty good advancement for cost savings.
- Chris, Serverless@AWS
Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.
66$ for running a AWS Lambda with 128 for a year seems very expensive.
If you're running it continuously for a year, then you should probably be using a reserved instance and not lambda. Lambda is for short bursts, not 1 year of continuous use.
Necessary change. Now writing stuff in fast languages suddenly matter in cost, changing the landscape of when these solutions might become viable for a chase.
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.