This content originally appeared on Level Up Coding - Medium and was authored by Daniel Costa
Running Lambda Functions Faster and Cheaper
A guide on how a simple configuration can make your functions faster and cheaper
Disclaimer: I'm not speaking on behalf of Amazon. Opinions are my own.
So, are you telling to me that I can run code in lambda faster and pay less doing that? Yes, I am!
Will you tell me how? Yes, I will!
First, let's start with the rationale behind two important points:
1 - How Lambda functions allocate CPU
Although CPU is not an explicit configuration on Lambda, it is determined based on another important configuration: Memory.
According to AWS documentation [ref]:
Q: How are compute resources assigned to an AWS Lambda function?
In the AWS Lambda resource model, you choose the amount of memory you want for your function, and are allocated proportional CPU power and other resources. For example, choosing 256MB of memory allocates approximately twice as much CPU power to your Lambda function as requesting 128MB of memory and half as much CPU power as choosing 512MB of memory. To learn more, see our Function Configuration documentation.
2 - How Lambda functions are billed
At the time of this post, disregarding free tier, lambda is charged by calculating
As we can notice, price per request is a variable that doesn't depend on Memory and Duration, so, can't be decreased by fine-tuning lambda configuration.
On the other hand, the first parameter is based on both memory and duration. As GB-second price is a constant defined by AWS and total of requests depends on service's architecture and load, we have a piece of the pricing equation where we can work to decrease the final price, which is:
In the end, we want to minimize the result of (memory in gigabytes) * (duration in seconds) in order to pay cheaper by executing lambda functions.
But, in a scenario where we already have a running lambda function, where the code is already optimized and duration decreasing is not so simple, how can we work on minimizing this? Let's check!
The ace in the hole: Minimizing lambda's duration and pricing by increasing the memory and CPU
So, in order to explain better the logic, let's set a few parameters.
The current price of GB-second for x86 architecture is $0.0000166667 for every GB-second and the price for requests $0.20 is per 1M requests [ref].
In our hypothetical scenario, we have a code that runs in a lambda with 128MB, with an average duration of 700ms. Also, this code runs 250 million requests monthly.
So, in this case, the pricing would be:
As mentioned before, the ace in the hole is to minimize
that in this case is 0.125 * 0.7 = 0.0875.
As an example, if we minimize 0.0875 in 10%, to 0.07875, so the final price would reduce from $414.58 to $378.12.
Considering that one of the aspects of the duration of a code is the available capacity of Memory and CPU, so, increasing the memory in Lambda can drastically reduce the execution duration.
The main point is: increasing the memory also increases one of the two multipliers in this equation, so, the second equation, that is duration, must decrease at a higher rate than the memory increased in order to have a worthy tradeoff.
In the example above, if we increase the memory to 256MB (2x 128MB) so it'd be worth it if the duration decreases to less than half.
In the table, we can notice that doubling the memory (from 128MB to 256MB) cuts the duration in half (from 0.7 to 0.35), so in the end the result is the same.
Our main goal is to decrease our duration in a rate higher than the increase of memory
Below we can see how this formula applies and shows that increasing memory from 128MB to 256MB is worthy when the duration is decreased from 700ms to 300ms
Finding the right memory configuration for my application in practice
The main goal to find the right configuration is to detect the threshold where the memory increase doesn't apply to the formula above.
There is a moment where increasing the Memory doesn't decrease the duration, and that's when you should stop.
The graph below shows how is the common pattern. The curve may vary depending on the application, the language, if it's I/O bound or CPU bound, and other factors.
I executed the code below 100x for distinct memory configurations (128MB, 256MB, 384MB, 512MB, 640MB, 768MB, 896MB, 1024MB, 1280MB, 1536MB, 2048MB, 3072MB, 4096MB) and calculated the memory * duration value and the final price for 250 million requests.
def lambda_handler(event, context):
for i in range(0, 300):
for j in range(0, 300):
for k in range(0, 300):
sum_of_indexes = i + j + k
As we can see, for this code, the cheaper configuration is 1536MB, that runs in 2415ms in p90 with a total price of $15,143.78 for 250 million execution.
The same code with 128MB would run more than 12x slower (30065ms) and would cost almost 4% more expensive ($15,708.80).
Step by Step
Basically, what you need to do to configure your lambda function memory is run your code N times (10~30 times might be enough) in order to get an average duration for every possible memory configuration until you notice that memory * duration is increasing too much. Then, you should pick the memory configuration that has the best tradeoff between price and duration.
Conclusion
Understanding the details of how the tools and services you use to operate and charge is very important in order to be able to configure it the best way possible.
Sometimes, we assume that using more resources means paying more, but it's not always true. When we talk about Cloud Computing, a resource is not measured only in hardware/capacity, but also in time.
Running Lambda functions Faster and Cheaper was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Daniel Costa
Daniel Costa | Sciencx (2021-11-30T16:29:50+00:00) Running Lambda functions Faster and Cheaper. Retrieved from https://www.scien.cx/2021/11/30/running-lambda-functions-faster-and-cheaper/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.