Live data from Hacker News

Tips to Optimize Your AWS Lambda Performance

medium.com

11–14 of 14 posts

Re: Tips to Optimize Your AWS Lambda Performance

#12
post #6

Earlier quoted context omitted.

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 instanc…

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

Re: Tips to Optimize Your AWS Lambda Performance

#13
post #8

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 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…

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.

Re: Tips to Optimize Your AWS Lambda Performance

#14

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’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.

Post reply on HN