Hi! Do you use Lambda Power Tuning? Reach out!

[alexcasalboni]

Hi,

I'd love to hear about how you've been using AWS Lambda Power Tuning for your projects and what optimization results you've achieved, whether in production or while prototyping.

You can find me at acasal@amazon.com or on Twitter/LinkedIn 👌

[savnik]

@alexcasalboni just tested it out in our playgrond environment in @BlackbirdHQ - and it is very interesting! We will try it out on our real lambda api services soon and update you.

[alexcasalboni]

@savnik great! feel free to ping me if you need help or if you have feature requests! (here, LinkedIn or email is OK)

[savnik]

@alexcasalboni when you calculate cost, is the cost based on 100ms billing or 1ms billing interval?
As you probably know AWS changed billing interval at this year reinvent for lambda.

[alexcasalboni]

Hi @savnik! The tool is now using the new 1ms billing (see #116).

I'm going to update some references and screenshots in the documentation asap too.

[selzinga]

Alex, I just found your project and this is outstanding! I have been playing around with it and the output so far has been very useful. I would go so far as to say this should be a standard part of the AWS compute optimizer for lambda. Very nicely done, thank you for providing this!

[alexcasalboni]

Thanks for your feedback and kind words, @selzinga 🙏
Feel free to reach out or open a new issue in case of issues or feature requests :)

[brendonparker]

I'm playing with it. Pretty neat! Is there any way to get the raw data. Curious to see the min/max times, not just the average.

EDIT
Just wanted to say, this is totally awesome. Saved me so much time in setting up some quick benchmarks.

[selzinga]

I'm playing with it. Pretty neat! Is there any way to get the raw data. Curious to see the min/max times, not just the average.

You can grab the raw data from the Cloudwatch logs. It is grabbing the Report lines with the Duration for each function and you can inspect those manually. I found it worth checking the logs anyway to look for any unexpected errors in the runs.

[alexcasalboni]

Yes! And you can also check the intermediate results (pre-aggregation) in the Output of the Executor step, either via management console or via API. This is the same raw data that’s plotted in the visualization URL (raw execution time and cost for each power config).

[uglow]

Yes, I've been using it for 3 months and it's great! For the project I'm working on, we had a lot of existing payload files which I didn't want to copy into the PoerTune config. So I wrote a NodeJS-version of the execution script which allows the config files to include external JSON or JS files (which have a default exported function (and also allow for arguments to be passed to the function)). This keeps the config files small and allows us to dynamically build the payload when required (e.g. converting a PDF to base64)

[alexcasalboni]

Hey @uglow 👋 thanks for sharing!

Have you considered using the new S3 payload integration? (documentation here)

The feature was meant to support large payloads (above the Step Functions limit), but it sounds like a good fit for your situation 😄 With a combination of S3 payloads and weighted payloads, you should be able to reuse most of your existing files without maintaining your own custom NodeJS version of Lambda Power Tuning 👌