Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Lambda Cold Start Times

filia-aleks.medium.com

Post reply on HN
Print view View original

101–110 of 233 posts

Re: AWS Lambda Cold Start Times

#101

Post by nuerow »

alex_duf wrote: post #83
earthboundkid wrote: post #75

Earlier quoted context omitted.

7s cold start is weird. I think there has to be more to the story than that.

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 worked on JDK Lambdas where cold starts were close to 20s due to their choice of dependency injection framework (Guide, the bane of JDK lambdas) which was shaven down to half that number by simply migrating to Dagger. I've worked on other JDK lambdas which saw similar reductions in cold starts just by paying attention to how a Redis client was configured.

Just keep in mind that cold start times represent the time it takes for your own code to initialize. This is not the lambda, but your own code. If you tell the lambda to needlessly run a lot of crap, you can't blame the lambda for actually doing what you set it to do.

Re: AWS Lambda Cold Start Times

#102

Post by zoul »

alex_duf wrote: post #83
earthboundkid wrote: post #75

Earlier quoted context omitted.

7s cold start is weird. I think there has to be more to the story than that.

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.

Also, cases where you can cache the responses for some reasonable time and revalidate in the background.

Re: AWS Lambda Cold Start Times

#103

Post by meekins »

cmcconomy wrote: post #59
secondaryacct wrote: post #46

Earlier quoted context omitted.

My company is moving away from datacenter and into Azure and I have to get the az900 this week, it doesnt bode well. And I was so happy to leave the clusterfuck of 300 aws lambda I was working with in my prev company. What an expensive fad, and no engineer is ever consulted ...

There are things I like, such as the consistent and pervasive security model with Azure AD. I don't even mind running stuff on App Services. I just find their commodity serverless offering in particular is subpar

> consistent and pervasive security model with Azure AD

Wait, this is the first time I hear this about Azure. Could you elaborate? It is possible that things have improved significantly since I last worked with Azure but lack of a consistent security model (like IAM on AWS) to control human and service (Azure Functions, App Service apps etc) access to specific resources (Cosmos databases, EventHubs etc) especially painful.

Re: AWS Lambda Cold Start Times

#104

Post by nuerow »

ctvo wrote: post #92
nuerow wrote: post #85

Earlier quoted context omitted.

> This is another example of AWS over marketing Lambda. Lambda is horrendously expensive when requests pass a certain level per second. I feel this is a gross misrepresentation of AWS Lambdas. AWS lambdas are primarily tailored for background processes, event handlers, and infrequent invocations. This is how they are sold, including in AWS' serverless tutorials. Even though they can scale like crazy, and even though…

> I feel this is a gross misrepresentation of AWS Lambdas. AWS Lambda is a serverless compute service that lets you run code without provisioning or managing servers, creating workload-aware cluster scaling logic, maintaining event integrations, or managing runtimes. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code as a ZIP fi…

> AWS Lambda is a serverless compute service that lets you run code (...)

So? It can run your code the way you tell it to run, but you still need to have your head on your shoulders and know what you're doing, right?

> How is it widely known?

It's quite literally covered at the start of AWS's intro to serverless courses. Unless someone started hammering code without spending a minute learning about the technology or doing any reading at all whatsoever on the topic, this is immediately clear to everyone.

Let's put it differently: have you actually looked into AWS's docs on typical lamba usecases, lambda's pricing and lambda quotas?

> That's what's I mean by over marketing here. Requiring insider baseball knowledge (...)

This sort of stuff is covered quite literally in their marketing brochures. You need to even be completely detached from their marketing to not be aware of this. Let me be clear: you need to not have the faintest idea of what you are doing at all to be oblivious to this.

There's plenty of things to criticize AWD over, but I'm sorry but this requires complete ignorance and a complete lack of even the most cursory research to not be aware.

Re: AWS Lambda Cold Start Times

#105

Post by fulafel »

Container based lambda image configurations (vs zip based) would be a good addition to this comparison. People use them eg to get over the zip based lambda size limit.

Also maybe mentione provisioned concurrency (where you pay AWS to keep one or more instances of your lambda warm).

Both of these are supported by Serverless framework btw.

Re: AWS Lambda Cold Start Times

#106

Post by time0ut »

fulafel wrote: post #105

Container based lambda image configurations (vs zip based) would be a good addition to this comparison. People use them eg to get over the zip based lambda size limit. Also maybe mentione provisioned concurrency (where you pay AWS to keep one or more instances of your lambda warm). Both of these are supported by Serverless framework btw.

Definitely. In my experience, docker image based Lambdas had consistently poor (>3s) cold starts regardless of memory. I hope it will eventually improve as it is a much nicer packaging approach than ZIP file.

Also, it would have been nice to include ARM vs x86 now that ARM is available.

Re: AWS Lambda Cold Start Times

#107

Post by e3bc54b2 »

I just want to appreciate the article. Starting with non-clickbait title, upfront summary, detailed numbers, code for reruns, great graphs, no dreamy story and no advertisement of any kind.

It is hosted on Medium but the author has done a banging great job, so gets a pass. If he is reading, excellent work!

Re: AWS Lambda Cold Start Times

#108

Post by cmcconomy »

meekins wrote: post #103
cmcconomy wrote: post #59

Earlier quoted context omitted.

There are things I like, such as the consistent and pervasive security model with Azure AD. I don't even mind running stuff on App Services. I just find their commodity serverless offering in particular is subpar

> consistent and pervasive security model with Azure AD Wait, this is the first time I hear this about Azure. Could you elaborate? It is possible that things have improved significantly since I last worked with Azure but lack of a consistent security model (like IAM on AWS) to control human and service (Azure Functions, App Service apps etc) access to specific resources (Cosmos databases, EventHubs etc) especially pa…

some of it is wonky, such as the login model for postgres on Azure SQL (you create login-capable postgres groups that exactly mirror the name of an Azure AD group, and then the "password" you pass in is actually a JWT proving YOU are in fact a member of that AD group -- so you have to hit a funky endpoint to get a time-limited "password")

Re: AWS Lambda Cold Start Times

#110

Post by [deleted] »

lostcolony wrote: post #91
_fat_santa wrote: post #4

At my last job we built an entire API on top of serverless. One of the things we had to figure out was this cold start time. If a user were to hit an endpoint for the first time, it would take 2x as long as it normally would at first. To combat this we wrote a "runWarm" function that kept the API alive at all times. Sure kind of defeats the purpose of serverless but hey, enterprise software.

"To combat this" Did you actually need to? That's one of the things that always threw me with complaints about cold starts - how many apps/etc do I use daily where I interact, and there's a 10 second delay before something happens? The answer: quite a lot. Yeah, we can do better. And in fact, with Serverless, -most users will experience better-. It's only when load is increasing that you see those delays, and then it…

[deleted]
Post reply on HN