Feature request: Improve Lambda Layer Performance

[perpil]

Use case

I've been doing some benchmarking of using the lambda layer vs bundling the SDK using esbuild. There appears to be a noticeable performance penalty in using the lambda layer on coldstarts. I'm using dynamic import and importing Tracer, Logger, Metrics and initializing each of them in my initialization. I'm also making calls to secrets manager in initialization so I've timed them and removed their impact from the normalized init duration. I'm seeing a repeatable impact of 100+ ms when using the layer.

init duration	secrets loading	normalized	lambda layer	delta	notes
849	121	728	none	+0 ms	This is with bundling using esbuild
1089	167	922	18	+194 ms	This is Lambda layer 18
994	112	882	20	+154 ms	This is Lambda layer 20

It's possible I've overlooked something, and I'll admit, my sample size is low but repeatable. This has more on the esbuild flags I'm using: https://speedrun.nobackspacecrew.com/blog/2023/09/23/optimizing-lambda-coldstarts.html

Solution/User Experience

If possible, conduct a similar benchmark and explore using esbuild or other techniques that could reduce the impact of using the layer. If there remains a performance penalty vs. bundling the SDK, document it.

Alternative solutions

No response

Acknowledgment

• [X] This feature request meets Powertools for AWS Lambda (TypeScript) Tenets
• [X] Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, Java, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[am29d]

Hey @perpil

thanks a lot for taking your time and looking into the performance of the layer 🙏.

This is something hat has been on our radar for a while and we will investigate it very soon. We are confident that using layer will not improve the performance, but it shouldn't also be a impactful increase. To get the best performance, it's best to bundle and tree shake into a single file.

The layer you tested has only tracer, metrics and logger. In our next release we will include all utilities AND selected aws-sdk clients, you can check this comment in #1712 . This will simplify the layer usage and prevent imports resolution issues, especially for node16 runtime. While we focused to keep the layer size small, we did not run any performance tests.

I am curious to see how the new layer version will perform. Is there a chance for you share the setup how you ran the experiments, so we can better understand the results. I am no expert on performance testing so this will also help me to learn a bit more about that.

Thank you.

[perpil]

Is there a chance for you share the setup how you ran the experiments, so we can better understand the results. I am no expert on performance testing so this will also help me to learn a bit more about that.

I should be able to create a minimal repo you can use to experiment. It may take some time to get to it, but I'll send a link when I've built it.

[perpil]

I noticed layer 21 was released today so I've added it to the table.

init duration	secrets loading	normalized	lambda layer	delta	notes
849	121	728	none	+0 ms	This is with bundling using esbuild
1089	167	922	18	+194 ms	This is Lambda layer 18
994	112	882	20	+154 ms	This is Lambda layer 20
1053	159	894	21	+166 ms	This is Lambda layer 21

[perpil]

Here's a quick repo that you can comment on and off layers and see the results in x-ray/cloudwatch. It uses serverless, but I'm not doing anything that can't be done with the CDK. Instructions here.

[dreamorosi]

Thank you @perpil, we'll take a look and go from there.