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

221–230 of 233 posts

Re: AWS Lambda Cold Start Times

#221

Post by laurencerowe »

dralley wrote: post #218
laurencerowe wrote: post #201

Earlier quoted context omitted.

Couldn't this also have been handled efficiently in Lambda had it been configured to use batching? (Assuming it was implemented as async invocations driven by a queue of some sort.) It does seem unfortunate that Lambda cannot be configured to support concurrent synchronous invocations for serving HTTP requests concurrently.

This is a bit like asking if you can make a coal-rolling pickup truck more environmentally friendly by letting your friends carpool with you. Technically, yes, but it's kinda missing the point.

I guess you're paying a 5x premium for Lambda in the constant usage scenario, a similar premium as on-demand vs spot instances.

4GB m6g.medium $0.0385/hour

4GB Lambda works out at $0.1920/hour

It's been a while since I last used queue driven autoscaling groups, but https://aws.amazon.com/blogs/compute/scaling-your-applicatio... has startup time of about 4 minutes from scratch or 36s from a paused instance in a 'warm pool.' vs less than a second for Lambda in the original article. So the decision ends up coming down to responsiveness vs cost. Presumably Fargate comes somewhere in between.

Re: AWS Lambda Cold Start Times

#222

Post by wpietri »

randomdude402 wrote: post #220
rmbyrro wrote: post #219

Earlier quoted context omitted.

Sure. But isn't this valid to any tech? As I pointed, one could make stupid use of expensive machine with dozens of cores as well...

Right, but at least with the expensive machine, one is making a conscious decision to spend a certain, known amount.

Exactly. These people thought they were using the tech well. They weren't. I like stories of tech gone wrong as examples to learn from. I thought others might as well.

Re: AWS Lambda Cold Start Times

#223

Post by iudqnolq »

sudhirj wrote: post #74
wongarsu wrote: post #67

Earlier quoted context omitted.

It's an excellent product for glue code between the various AWS services. Just about every AWS product can trigger Lambda functions, so if you want to run image recognition whenever a new image is uploaded to S3, Lambda is the way to do that. They also make great cron jobs. But for some reason Amazon likes to sell it as a way to run any web application backend, as if that was a good use case.

It can be. We run dynamic image resizing (have a couple million image high quality originals in S3, and customers request sizes based on their screen). Each request is handled by a lambda, and even though these are memory intensive operations we never need to worry about servers or running out or RAM or circuit breakers or anything. Whatever the load it just works. The actual operations take on the order of 100ms, so…

> Say you open a page with a 100 images on it for example. With lambda the all images are resized for you in parallel, so total 100ms. If this was servers, would have to run 100 servers to give you the same performance

You're probably just simplifying, but to clarify servers can totally do multiple things at once. That's how Amazon runs multiple lambdas on one physical server.

Re: AWS Lambda Cold Start Times

#224

Post by jamesfinlayson »

secondaryacct wrote: post #46
cmcconomy wrote: post #32

My experience with cold starts in Azure Functions Serverless is pretty awful. Like most other Azure services, their affordable consumer grade offerings are designed from the ground up not to be good enough for "serious" use. Cold start times compared to Lambda are worse, and in addition, we would get random 404s which do not appear in any logs; inspecting these 404s indicated they were emitted by nginx, leading me to…

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

> 300 aws lambda

I'm living that now but moving it out of Lambda and into ECS it as fast as I can.

Re: AWS Lambda Cold Start Times

#225

Post by jamesfinlayson »

jacurtis wrote: post #122
lostcolony wrote: post #91

Earlier quoted context omitted.

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

There is actually a really awesome middle-ground that AWS offers that no one seems to talk about. That is using ECS + Fargate. This gives you (IMHO) the best of both worlds between Lambda and EC2. ECS is Elastic Container Service. Think docker/podman containers. You can even pull from Dockerhub or ECR (Elastic Container Registry - amazon's version of dockerhub). ECS can then deploy to either a traditional EC2 compute…

Agreed - I'm in the process of moving hundreds of Java Lambdas into a Spring application running in ECS. It costs more to run, but I get flexibility with the scaling parameters and I can more easily run my application locally too. I'm still stuck on AWS but less so than with Lambda.

Re: AWS Lambda Cold Start Times

#226

Post by sudhirj »

iudqnolq wrote: post #223
sudhirj wrote: post #74

Earlier quoted context omitted.

It can be. We run dynamic image resizing (have a couple million image high quality originals in S3, and customers request sizes based on their screen). Each request is handled by a lambda, and even though these are memory intensive operations we never need to worry about servers or running out or RAM or circuit breakers or anything. Whatever the load it just works. The actual operations take on the order of 100ms, so…

> Say you open a page with a 100 images on it for example. With lambda the all images are resized for you in parallel, so total 100ms. If this was servers, would have to run 100 servers to give you the same performance You're probably just simplifying, but to clarify servers can totally do multiple things at once. That's how Amazon runs multiple lambdas on one physical server.

They can, and these are already multi core operations. If takes 4 cores 100ms to do this operation, so on a server with 4 cores doing a 100 of them takes 10 seconds, while on lambda it takes only 0.1 seconds to to them all in parallel.

Re: AWS Lambda Cold Start Times

#227

Post by tenaciousDaniel »

gbourne wrote: post #194
tenaciousDaniel wrote: post #121

Earlier quoted context omitted.

Yeah I tried that, it doesn't work. Ultimately the provisioning algorithm is a black box.

Why didn't the Firebase minInstances work for you? I found amazing performance benefits, but at a $ cost. I actually forgot[1] a function to set a minInstance and a user complained that this particular functionality was slow (compare to the rest of the site). However, it isn't cheap. You also want to be sure your code is optimized[2]. For example, don't require module packages unless the function needs it, else you'r…

No idea why. Yeah we're trying all the usual techniques.

Re: AWS Lambda Cold Start Times

#229

Post by wmfiv »

WatchDog wrote: post #205
wmfiv wrote: post #76

Earlier quoted context omitted.

Insanely expensive is definitely a flexible term. I think numbers help here. Provisions Concurrency $8.64 / GB / month 256 MB per Lambda (Assuming Python, Ruby, NodeJS, or Rust) $2.16 per Lambda per month A lot of organizations can probably make a good business case for keeping 100s or even 1000s of Lambda's warm. You also don't need to keep them warm 24x7, can get an additional 12% discount using savings plans, and…

1 GB of lambda provisioned concurrency is $10.95 USD a month in us-east-1. That's what you pay for your lambda sitting there doing nothing. You can get an on-demand ec2 instance with 1 GB of RAM, for $9.13 USD a month, or $6.87 if you get a reserved instance. You can fully utilize those instances the whole month. Source: https://calculator.aws/#/estimate?id=7e1d1c2f32a2c63ba4ded19...

Yeah I used the ARM price. I should have pointed that out. It's definitely a tradeoff. Here's a few things I think are advantageous for Lambda,

* Integration with all the AWS Event Sources.

* Faster autoscaling.

* No need to setup a VPC (subnets, NAT gateway, security groups, VPC endpoints potentially, etc)

* No need to setup autoscaling, multi-AZ, etc.

* No need to support long lived instances.

I don't think one is always better than the other.

Re: AWS Lambda Cold Start Times

#230

Post by ctvo »

nuerow wrote: post #104
ctvo wrote: post #92

Earlier quoted context omitted.

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

You've been going on and on. I linked you the AWS marketing page on Lambda that includes it scales with no infrastructure and can be used for all use case.

You've had two chances to cite something on their vast marketing and documentation other than marketing brochures (are you serious?) and AWS specific training, paid or otherwise.

You even quoted the wrong part of the marketing spiel.

Just upload your code as a ZIP file or container image, and Lambda automatically and precisely allocates compute execution power and runs your code based on the incoming request or event, for any scale of traffic

ANY scale of traffic, requests or events. Just upload a ZIP or image and you're done. We know that isn't the case, don't we? Even without AWS sales people showing up personally to provide us marketing brochures they wouldn't put on their website.

Post reply on HN