Giter Site home page Giter Site logo

Comments (3)

NeilJed avatar NeilJed commented on June 18, 2024 2

@alexcasalboni - thanks for the reply and thoughts.

Yes I agree that in most cases it probably doesn't matter when things average out. The reason I investigated is that
we've been trying to figure out the pros/cons of using ZIP vs Container plus we're also looking at running Rust lambdas both of which charge for the init phase.

For those that run "warm" it's maybe 1 in 10,000 invocations that are cold but I can imagine there are maybe less frequently called event driven lambdas that might have a higher rate of cold starts hence it's important.

But yes, I guess using Billed Duration is best as that afterall is the time you're being billed for.

I'll have a go at a PR - JS isn't my strong suite but you've got to learn sometime. :)

from aws-lambda-power-tuning.

alexcasalboni avatar alexcasalboni commented on June 18, 2024 1

Hi @NeilJed, thanks for reporting this!

I believe it's an interesting observation and it can impact cost considerations for functions that have a very high, non-free initialization time, depending on how you use Lambda Power Tuning.

For historical reasons (before 1ms-billing was introduced in late 2020), the tool used Duration because it represented invocation time much better than Billed Duration - which was rounded at 100ms intervals.

Today this isn't true anymore, but my intuition says the power-tuning impact should be fairly low. Because the "durations" are averaged and outliers are excluded by default (see here and here), using Duration should not have impacted power-tuning results considerably so far. Unless you use a very low num, parallelInvocation=true, discardTopBottom=0, and the init time is considerably long & not free.

Let me explain 😄 (very long thinking-out-lout moment - skip to bottom for final results)


As pointed out in the article you shared:

The init phase gets two unthrottled vCPUs, even at very low memory configurations

So for the sake of power-tuning itself, the init duration does not depend on the memory/power configuration and someone might argue that Lambda Power Tuning shouldn't include init time in the analysis because 1/ it's power-independent, 2/ it's often free, and 3/ the tool excludes cold starts from the analysis by default anyway.

That said, when discardTopBottom=0, cold starts are included in the analysis and using Billed Duration (instead of Duration) would indeed affect the analysis, causing the average duration to be higher. Please note this would happen for all power values, so I'd still expect the final power-tuning results to not be affected (e.g. if 512MB was the optimal value, it probably still is).

Another important parameter to keep in mind is parallelInvocation. When false, you only get one cold start per power value, so it's easy to discard with discardTopBottom>0. When true, you can experience multiple cold starts per power value. Since new Function Versions/Aliases are created each time you power-tune, the number of cold starts should be consistent across many power-tuning executions.

Basically, there are 8 major cases to consider.

If parallelInvocation=false:

  1. discardTopBottom>0 - all cold starts are ignored - no big deal (Duration ~= Billed Duration)
  2. discardTopBottom=0 and your init time is very short - no big deal
  3. discardTopBottom=0 and your init time is considerable but free - no big deal
  4. discardTopBottom=0 and your init time is considerable and not free
    • this is probably worth fixing because Duration << Billed Duration, but should have a minor impact on the reported average duration because you only get one cold start per power value

If parallelInvocation=true:

  1. discardTopBottom>0 - most cold starts are ignored - no big deal
  2. discardTopBottom=0 and your init time is very short - no big deal
  3. discardTopBottom=0 and your init time is considerable but free - no big deal
  4. discardTopBottom=0 and your init time is considerable and not free
    • this is definitely worth fixing because Duration << Billed Duration and it might have a major impact on the reported average duration

Apologies for the long reply, I needed to think out loud and confirm that the current implementation works fine for the largest majority of use cases.

To summarize, it totally makes sense to use Billed Duration in all situations 🚀

Will work on a PR to implement this (with a regex) asap 👌 Or do you feel like submitting a PR yourself?

from aws-lambda-power-tuning.

alexcasalboni avatar alexcasalboni commented on June 18, 2024

Closing this :)

from aws-lambda-power-tuning.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.