Tips to Optimize Your AWS Lambda Performance
medium.comIf you actually have a consistent/constant load then you don't need to pay for Provisioned Concurrency to prevent cold starts since you technically will have the equivalent with your actual usage.
Also, if you're using Lambda to ingest data consider using one lambda as a dispatcher to SQS and another hanging off that SQS queue for processing. That allows you to control concurrency better since you can set the batch size + concurrency on the SQS trigger.
By doing the above makes your critical path super-fast, because you're doing no processing. That works great if the incoming data needs no response from the back-end.
@mannyv Really great points !
"You should set your PC value equal to your peak TPS divided by the execution time. For example, if you have a peak of 50 TPS and your execution time is half a second, the most effective PC value would be 25."
This confused me. Wouldn't 50 / 0.5 be 100?
I did not think it that way, I understand why it is confusing. Think of it this way you have 50 invocations every second, and you take half a second to process each one. Which means at any given time, on average you will have 25 instances of your lambda running. Which means if you set your PC to 25, you pretty much guarantee that every invocation is warm.
Remember that PC is nothing but total number of lambda instances that AWS keeps warm and ready to go.
If you had 50 invocations every second and your execution time was 2 seconds, would you set it to 100? If that's the case, you would multiply the invocations per second by the process time.
Yes, maybe that’s a better way to put it
I still don't understand why anyone would use lambdas - except if you 1) trust Amazon blindly, and 2) have no understanding whatsoever of how a server works, and therefore absolutely unable to set one up (even as a AWS instance, LOL).
From my experience, they are clumsy, complex to set up, to manage, you can't easily have CI/CD (I still don't know how you get the code of a lambda from and to git ?!?!), etc, etc...
Is it just me ? Am I alone ?
:)
It is just you!
Seriously, the reason you use lambdas is that they're small self-contained chunks of functionality that you need to scale out.
Let's take an easy example: you want to ingest tracking metrics.
You can write this as a server or as a lambda. For a server you'd listen on port 80 for POST or GET requests, then take that and write it to your data store. You can do this pretty easily in express/node.
Now the question is, how do you scale that up to a few hundred requests per second? How concurrent is your express app? Are you going to run out of memory on your server because you didn't set the TCP buffer sizes for server sized usage? How do you take your service offline for upgrades/updates? Are you going to crush your database/datastore with hundreds of writes a second? If your ISP barfs are you OK with losing data for that time period? What happens when all of your clients try to connect at once because of a regional power failure?
From a code point of view, what if some random change in your code somewhere causes your ingestion stuff to fail?
Seriously, you don't have to deal with any of this crap if you don't want to. For 1 request every few seconds who cares what you use. But once you start scaling your problems with a server side solution become more and more work to handle.
Again, if you don't need scale don't use AWS. You can always do it cheaper with a server from lowendbox.com.
As for vendor lock-in, well, it's trivial to design your lambdas so you can drop them into a server-side solution (or vice versa). And when you think of vendor lock-in you have to consider also that a bespoke solution is locking in you as the vendor.
I've inherited an high rps API built with api gateway + lambda + dynamodb and I've found easier and way cheaper to move the thing on ec2. Less headaches too. Resources can be managed more efficiently, cold starts are not a thing, you have predictable latencies, it does serve way more concurrent requests at a fraction of the cost. I go for lambda when i need a service that can scale down, but not when i need to scale up efficiently. Debugging is easier, connection pooling is not an accident, processes' limits and isolation can be managed anyway.
It’s always funny when you read something and think the exact opposite thing for every point.
I guess what initially converted me was dealing with a data flow that hovered at about 10 requests/min and then every hour jumped to 10k requests/min. Being able to do that without thinking about scaling or cost really changed the way I imagined data flows in the backend.
I guess now that I have boilerplate of code that works and its quickly deployed and tested with GH actions, I consider it a no brainer for most workflows.
> you can't easily have CI/CD (I still don't know how you get the code of a lambda from and to git ?!?!),
I had to go through a couple of attempts at it before settling on building and pushing Docker images via GitHub Actions. Now deployment is a breeze.
However, I don't know if it's optimum to use Docker images in terms of performance.
> I still don't know how you get the code of a lambda from and to git ?!?!),
I have this setup myself, let me dig it up and will reply in a later post