Four Ways to Improve Your AWS Lambda
How to polish your Lambda Function
Hello, today I want to talk about how you can boost the performance of your Lambda by polishing it. Let's delve into four ways to improve the init phase of your Lambda function, balance the cost and performance, trace your code with X-Ray and ultimately get to a faster and scalable function.
Keep the variable outside the handler
If you have an object you need to initialize and reuse for every Lambda request, you can place it outside of the handler function.
The execution environment of Lambda stays active from 2 to 10 minutes if no request comes.
After the first start, the AWS Client in Node.js will reuse the same connection in the next execution making the following requests faster.
Another example it’s the reuse of a variable that contains a value, as in Parameter Store, in order to not reach the limits while you can store the value and use it in the next execution.
The INIT phase in Lambda executes the outside code: if you need to start a connection to a database this is a good moment to do it.
Rembember: if you use Provisioned Concurrency the code outside the handler will be executed.
Understand the power of layers
Did you know you can include all your dependencies in a layer? Avoiding them in the deployment package will optimise the performance, as a Lambda Function with small package is faster during the init phase.
Remember the AWS SDK v2 is already in the standard runtime, so you don’t need to include as dependencies.
Note: if you plan to use the AWS SDK v3 for Javascript it’s a good practice to add it in the layers instead.
Not just dependencies! You can also add your code to use it in all the functions that have the layer.
Inspect your code with X-Ray
You included multiple AWS resources in your code. Are you worried about the overall performance? You can add the X-Ray client in your code, it will allow you to trace all non AWS requests with the custom segment. In this way you can measure the global performance of your code.
Here it is the first execution of the function. As you can see, the initialization phase lasts about 556ms and includes the execution of layers and the code outside the handler.
Also, we see the GetParameter needed 500ms, sigh.
This is instead the duration of the second execution. There are no more initialization of the Lambda function and call to SSM for the value.
Remember: with X-Ray you can check the performance of all services or only of a segment of your code.
Balance your RAM accordingly
If you want to increase the speed of your Lambda you can also increase the RAM of your Lambda function. The minimum is 128mb and the maximum is 10240mb.
The cost of an execution will increase, decreasing the execution time. To do so, we can use Casalboni’s tool to see the cost per execution ratio (you can learn more here).
How you can see, the invocation time is the same for all RAM tiers, and the invocation cost is increased per tier. We can check that at 128 mb the function has the lowest cost per invocation time, so it’s the best to pick.
You can find the source code of all these examples in the repository GitHub below.
Feel free to try and let me know if you have more tips on how to improve AWS Lambda Function. Check out my previous article about AWS S3 Select.
See you soon!
