https://dashbird.io/features/aws-lambda-serverless-monitoring/) to make it easier to profile Lambda memory usage and identify thresholds for this kind of benchmarking analysis.
The sharp rise in the line slope (chart above) for higher memory sizes caught my attention. From that point on, it has been reported — although not officially — that Lambda provides two cores. My hypothesis is that the processing power is split among cores and, since my job was using only one core, the test was actually punishing the dual-core function setting. That’s something to look more closely in a future test, with a task that can take advantage of multiple cores.
In terms of duration, the chart above seems to have no surprises, but I actually found something consistently weird in the results: 2048 MB always performs faster than 2304 and 2560 MB, which is unexpected. Zooming in to the highest memory sizes we can notice the difference.
It might be negligible since it represents roughly 2% in extra execution time. Nonetheless, if we’re running this function millions of times or if latency is super important, those extra milliseconds can be relevant.
Understanding exactly which factors are playing a role in producing these unexpected results is hard. Lambda infrastructure is sort of a black box. Maybe there are differences in hardware serving each request, which would introduce some undesirable variability in our tests. Bottom line is: if you want to optimize your Lambda usage for either the fastest execution or lowest cost, you should definitely benchmark your functions.
We’ve released the benchmarking function so that you can deploy and test your own Lambda functions for yourself.
To reap the benefits of a performance monitoring tool tailored for AWS Lambda, sign up today for Dashbird, it’s free and doesn’t require credit card.
Failure detection, analytics and visibility for serverless applications in under 5 minutes.