DEV Community

loading...

Discussion on: Deep dive: finding the optimal resources allocation for your Lambda functions

Collapse
adamcoster profile image
Adam Coster

I feel like I'm missing something here. The cost of lambda goes up roughly linearly with memory, as does performance, so without the 100ms binning of billing you'd expect things to more or less break even. Because of the 100ms step though it's generally better (for cost) to use less power. In your first example the billed cost actually goes up by 30% even though the time goes down by 30%. For fast functions (on the order of a small number of 100ms) it will generally be cheaper to use as little power as possible, because the 100ms billing rounding error creates substantial cost unless 100ms is small compared to execution time.

Collapse
alexcasalboni profile image
Alex Casalboni Author

Because of the 100ms step though it's generally better (for cost) to use less power.

This depends a lot on the use case. Some of the workload categories I've described do benefit from using more power (especially the CPU-bound ones) since it often results in lower average cost too.

In your first example the billed cost actually goes up by 30% even though the time goes down by 30%.

Thanks, I think you've found a typo in my first example. As I've reshaped that example a few times, in the latest version average cost is not constant anymore. The idea was that often you can double power and half execution time, resulting in the same average execution cost. I'll fix it now.

For fast functions (on the order of a small number of 100ms) it will generally be cheaper to use as little power as possible...

I think this is good advise only if you don't care about performance (i.e. for most asynchronous executions, where nobody is waiting for a response).

Some comments have been hidden by the post's author - find out more