AWS Lambda vs Cloud Functions (2nd gen) performance benchmark: 40% slower😱
AWS Lambda vs Cloud Functions (2nd gen) performance benchmark: 40% slower😱
In this video, we’re going to run a benchmark test between AWS Lambda and Google Cloud Functions.
👉 How to Manage Secrets in Terraform - • How to Manage Secrets in Terraform?
👉 Terraform Tips \u0026 Tricks - • Terraform Tips \u0026 Tricks: loops, if-st…
👉 ArgoCD Tutorial - • ArgoCD Tutorial for Beginners: GitOps…
💼 - I’m a Senior Software Engineer at Juniper Networks (11+ years of experience)
📍 - Located in San Francisco Bay Area, CA (US citizen)
🤝 - LinkedIn - https://www.linkedin.com/in/anton-putra
🎙 - Twitter - https://twitter.com/antonvputra
📧 - Email - [email protected]
👨💻 - GitHub - https://github.com/antonputra
=========
Source Code
📚 - GitHub: https://github.com/antonputra/tutoria…
#AWS #GCP #Serverless
Content
0.04 -> In this video, we're going to run a benchmark
test between AWS Lambda and Google Cloud Functions.
5.839 -> Recently Google Cloud introduced a new generation
of Cloud Functions; they call it gen 2.
11.7 -> It's simply a wrapper around Cloud Run, which
brings even more confusion.
15.99 -> For example, in the previous generation, to
allow unauthenticated access to the function,
21.13 -> you would need to grant a Cloud Functions
Invoker role to all users.
25.58 -> Since gen 2 is a wrapper around Cloud Run,
now, to achieve the same result, you would
30.89 -> need to grant the Cloud Run Invoker role to
Cloud Functions.
34.61 -> In the first benchmark test to establish a
baseline, we will create a simple function
39.49 -> that returns hello world and invoke that function
using its URL 1000 times.
45.32 -> In the second test, we will download a large
image from the S3 or GS bucket, depending
50.579 -> on the Cloud, then resize it to 400 by 400
pixels and save the result back to the bucket.
57.26 -> Then based on the results, we will design
a 3rd benchmark test.
61.29 -> In AWS, you can only give memory to your Lambda
function.
65.11 -> It allocates CPU power in proportion to the
amount of memory configured.
69.8 -> For example, if you need 1 vCPU, you would
provide 1,769 MB of memory to your function.
78.46 -> There are a bunch of other parameters, but
those are the most important ones.
82.56 -> Google Cloud Functions uses similar proportions.
85.18 -> We're going to allocate the same amount of
memory for both functions, which is 1Gb, which
91.33 -> results in a little more than half of the
virtual CPU.
95.38 -> Also, how quickly Lambda and Cloud Functions
can autoscale based on the load will play
100.89 -> an important role in this test.
102.64 -> You can find the source code for the functions
as well as terraform to reproduce this benchmark
107.32 -> test in my GitHub repository.
109.43 -> If you run terraform apply, you'll get a few
URLs that you can use to test your functions.
114.75 -> To run a benchmark, we're going to use a hey
tool.
117.45 -> It's a tiny golang app that sends some load
to a web application.
121.33 -> First of all, let's test the AWS Lambda hello
world function.
126.25 -> There are a few arguments that we need to
supply to hey.
129.2 -> First, we want to perform 1000 requests.
132.609 -> Then we want to spin up five workers to run
some requests in parallel.
137.05 -> Also, specify the GET method and provide the
URL for the function to invoke.
141.849 -> It does not have any output while it's running.
144.099 -> In the results, you can find the information
about the slowest request, fastest and average,
149.709 -> and a bunch of other staff.
151.4 -> And how many requests per second it served.
153.989 -> You also get a histogram with response distribution.
156.849 -> Here, for example, the average time of the
requests is 119 ms.
162.249 -> Also, it's important to take a look at latency
distribution and especially how long it took
168.19 -> to complete 95 and 99% of all requests.
172.37 -> For simplicity, I will just compare average
time.
175.439 -> Next, let's run exactly the same hello world
Google Cloud Function.
180.249 -> The results are slightly better.
182.169 -> The average time is only 110 ms, which is
around 8% faster.
187.939 -> And we got 44 requests per second instead
of 41 with Lambda.
192.17 -> I don't think you should rely on these particular
benchmarks except that we proved that our
197.169 -> serverless functions work.
198.709 -> We can also take a look at the concurrent
execution; that's how many functions were
203.409 -> created to serve the traffic.
205.969 -> In AWS, when you run short tests, metrics
are not very accurate, but still, we can see
210.53 -> that Lambda scaled from 1 instance to 3.
214.06 -> GCP also spun up 3 cloud functions for the
hello world test.
218.629 -> Now let's take a look at another function
to resize the image.
223.069 -> We have 3 golang functions, getImage to download
an object from the bucket, uploadImage to
229.06 -> save a new scaled-down image to the bucket,
and scaleImage to resize the image.
234.4 -> In GCP, we use google cloud sdk, so the code
will be slightly different but with the same
239.729 -> logic.
240.729 -> To test AWS Lambda that resizes the image,
grab the URL and use the same load test tool.
246.84 -> This test takes around 8 to 10 minutes to
complete.
250.199 -> In the results, we have the average duration,
which is 2.38 seconds, and 2 requests per
255.999 -> second.
256.999 -> 95% of the requests were completed in under
2.8 seconds.
261.16 -> Now run the same test with the Google Cloud
Function to resize the image.
265.96 -> The results are significantly slower.
268.4 -> The average duration is above 3 seconds, and
we only completed 1.5 requests per second,
274.87 -> which is 36% slower than AWS.
282.41 -> During this benchmark, AWS created five instances
of the Lambda function to resize the image.
288.38 -> On the other hand, Google doubles it to almost
ten functions.
292.75 -> Let's run the final test, in which we are
going to use AWS lambda, but instead of using
297.93 -> S3, we are going to download an image from
the Google Storage bucket, resize it and upload
303.99 -> it back.
305.01 -> Basically, the same thing that the google
cloud function does.
308.32 -> To grant permissions, you need to get the
credentials file and put it into your lambda
313.12 -> function and use the environment variable.
316.32 -> Results are a little bit surprising; AWS Lambda's
average duration is 2.47 seconds which is
322.68 -> still 31% faster than the native google cloud
function.
326.85 -> To conclude, AWS lambda is significantly faster
than Google Cloud Function.
332.14 -> The reason, in my opinion, would be the amount
and quality of CPU that is allocated to the
338.08 -> functions.
339.08 -> Based on the official data, in aws, you get
one vCPU with 1,769 MB memory, and in GCP,
347.99 -> you need 2048MB to get one vCPU.
351.46 -> There are other parameters that can affect
the function performance, such as networking
356.09 -> and auto-scaling.
357.09 -> Let me know in the comments why you think
Cloud Functions are slower.
360.91 -> Thank you for watching; take a look at another
benchmark between AWS lambda written in Golang
366.42 -> vs. Rust; you will be surprised by the results.
Source: https://www.youtube.com/watch?v=kB-fM31UQBM