3 ms·

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 funct

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.

abalone 9y ago
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.
- abritinthebay 9y ago
  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).
- wanghq 9y ago
  Those will still have cold start delay. A simple warm-up script only solves 0-to-1 problem, but not 1-to-n problem.
  - sozal 9y ago
    You may have a look at OpsGenie's Sirocco https://github.com/opsgenie/sirocco/tree/master/sirocco-warmup https://github.com/opsgenie/sirocco/tree/master/sirocco-warm...
    - wanghq 9y ago
      Awesome! Thanks.
- cnj 9y ago
  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.)

abalone 9y ago

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.

abritinthebay 9y ago
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).
wanghq 9y ago
Those will still have cold start delay. A simple warm-up script only solves 0-to-1 problem, but not 1-to-n problem.
- sozal 9y ago
  You may have a look at OpsGenie's Sirocco https://github.com/opsgenie/sirocco/tree/master/sirocco-warmup https://github.com/opsgenie/sirocco/tree/master/sirocco-warm...
  - wanghq 9y ago
    Awesome! Thanks.
cnj 9y ago
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.)