AWS Lambda Cold Start Times • Hacker News Board

Re: AWS Lambda Cold Start Times

#231

Post by oblio » Thu, Oct 14, 2021, 6:52 AM UTC

rmbyrro wrote: post #211

wpietri wrote: post #160

Earlier quoted context omitted.

Lambdas can be dirt cheap if you use them well. But that's always what happens. I recently saw a report about contractor who used them for crawling websites. Their client saw a surprise $12k bill for Lambda, when a simple Scrapy crawler on a low-end instance would have cost them Why? Because if you spin up a ton of Lambda invocations and have them sit around waiting for the network, you pay for each CPU to sit idle,…

This is poor architecture, not Lambda's fault. Same result would be achieved by paying tons of $$ for a high-end machine with dozens of cores, just to scrape one URL per core. They could have implemented asyncIO within just a few Lambdas - heck even one Lambda could certainly handle hundreds, if not thousands of ASYNC jobs at once, just as a cheap machine, as you pointed. They treated Lambda functions as threads or a…

I'm not sure I understand the point about asyncIO: yeah, the Lambda CPU isn't spinning, but don't they count actual runtime? So even if things are async, the Lambda still needs to be up to respond to the event when the async IO is finished.

Or do you mean handling things in an async way and Lambda passing the info on to another computing environment?

Re: AWS Lambda Cold Start Times

#232

Post by wpietri » Thu, Oct 14, 2021, 1:57 PM UTC

oblio wrote: post #231

rmbyrro wrote: post #211

Earlier quoted context omitted.

This is poor architecture, not Lambda's fault. Same result would be achieved by paying tons of $$ for a high-end machine with dozens of cores, just to scrape one URL per core. They could have implemented asyncIO within just a few Lambdas - heck even one Lambda could certainly handle hundreds, if not thousands of ASYNC jobs at once, just as a cheap machine, as you pointed. They treated Lambda functions as threads or a…

I'm not sure I understand the point about asyncIO: yeah, the Lambda CPU isn't spinning, but don't they count actual runtime? So even if things are async, the Lambda still needs to be up to respond to the event when the async IO is finished. Or do you mean handling things in an async way and Lambda passing the info on to another computing environment?

I think what they're talking about is using one Lambda to persist, handling many crawl requests. That doesn't make a ton of sense, as each Lambda has to make sure to push all its results and shut down before the max timeout is up, but it would technically work and be more efficient than what I described. Much better, though, just to use long-running spot instances, though, or just a regular instance running something like Scrapy.

Re: AWS Lambda Cold Start Times

#233

Post by alex_duf » Fri, Oct 15, 2021, 9:01 AM UTC

nuerow wrote: post #101

alex_duf wrote: post #83

Earlier quoted context omitted.

I've seen 30s on AWS, so it's not that surprising. They have now improved it greatly though. And yet I still believe it's a great technology, as always it's a matter of putting it on the right use case. Message consumption from a queue or topic, low traffic and low criticality API are two great use cases.

> I've seen 30s on AWS No, you've seen 30s on a random implementation running on AWS. If you write your lambdas without knowing what you're doing then you can't blame the technology for being grossly misused by you. Case in point: developing AWS Lambdas for the JDK runtime. The bulk of the startup time is not the lambda at all but the way the lambda code is initialized. This means clients and auth and stuff. I've wor…

>This is not the lambda, but your own code

And yet it magically came down to 10s when amazon improved their system. Specifically it became much faster to join a VPC.

And don't get me wrong: yes I was running some init code but not that much: load config from ssm, connect to a DB. I did bundle a lot of libs that didn't need to be there. But:

- fact is, it took 30s

- the use case didn't need it to be faster so I didn't care much

- the technology is still good, would recommend