Hacker News Reader

Comment by mark242 | Hacker News Reader

The easiest thing to do on AWS is just fire off a CloudWatch event. When your Lambda function gets updated, or even on a set schedule, you can invoke your function with whatever arguments you need. Presumably you could cook in a method that warmed everything up, and call that method.

View on HN

That's fine for functions that go cold, but what about additional containers that spin up when usage spikes? Don't those also suffer from cold start delays? I never hear people talk about that.

Depends on the container/instances. There are cold start delays but you can get it down to a minute or two if you really optimize (but... well, most people don't need to).

Those will still have cold start delay. A simple warm-up script only solves 0-to-1 problem, but not 1-to-n problem.

You may have a look at OpsGenie's Sirocco https://github.com/opsgenie/sirocco/tree/master/sirocco-warm...

Awesome! Thanks.

Yes, they also suffer from cold starts. When people talk about it, they usually measure the percentage of cold-started function calls, which mostly ends up being around 0.1% of all calls.

In a sense, you have to have a good amount of baseline traffic to end up with that problem, which reduces the percentual impact. So the problem is less pronounced than with a function that is very rarely run, where a high percentage of function calls are cold.

(In theory, the worst case where a CloudWatch trigger would be mostly useless is that a function is totally idle and removed from warm-state, and then gets a huge concurrent spike, is idle again, gets a spike etc. But that is not a realistic traffic pattern, I assume. It would also break with existing auto-scaling that would be even slower with bringing up new instances.)

Reply on news.ycombinator.com