Single Purpose and Monolithic Lambda Functions are two approaches to developing and deploying our applications (you can check the pros and cons here). But what are the differences from the performance perspective?
To answer this question, we develop two applications. One using .NET 6 Minimal API (Monolithic Lambda Function) and the other using the AWS Lambda Project Template (Single Purpose Lambda Function) from the NuGet package Amazon.Lambda.Templates, both are going to do the same (the code can be found here):
- Receives an HTTP request from API Gateway.
- Store the request in a DynamoDb table.
- Send a message to an SQS queue.
- Return an HTTP response.
For both Lambda Functions, we are using 512 Mb. For testing (three times), we are using K6 with the following workloads:
- One user for four minutes.
- Two concurrent users for four minutes.
- Three concurrent users for four minutes.
Let's take a look at the results of the first run:
As we can see the average response times are quite the same, and we could state that there is no difference between the two approaches. The real difference comes when we see the maximum response time which is related to the cold starts. The cold start produced by the Monolithic Lambda Function is higher than the Single Purpose Lambda Function option. This makes sense since the .NET 6 Minimal API has more code to load when compared to the AWS Lambda Project Template.
To confirm that the maximum response times are caused by the cold start, we enabled X-Ray in both applications to analyze the slowest requests (from the third run). Monolithic Lambda Function:
Single Purpose Lambda Function:
While the advantages of using the .NET 6 Minimal API to build our applications are great, there is a price to pay (longer cold start time) when using AWS Lambda as a deployment strategy. If your application needs to be as fast as possible on every request, we might suggest using the Single Purpose approach. And thinking even further, if the request duration is a requirement in your application, perhaps we could move away from the serverless approach and use Beanstalk or EKS to host our applications. Thanks, and happy coding.