5 ms·

When lambdas haven't been hit for 15mins the first hit after has a noticeably longer start time. It's due to deprovisioning/reprovisioning underlying resources

When lambdas haven't been hit for 15mins the first hit after has a noticeably longer start time. It's due to deprovisioning/reprovisioning underlying resources like network interfaces. Some people do crazy stuff like a scheduled task to hit their own service to combat this so AWS promised to solve it.

alexanderdmitri 8y ago
Even if you invoke your lambda function to warm it up in anticipation of traffic, you'll still hit cold starts if the lambda needs to scale out; the new machines are exposed to inputs "cold." Those crazy patterns trying to warm the lambda up are really crazy if you think about it because no one is using them is really aware of the underlying process(es) involved. "Why are you throwing rocks at that machine?" "It makes it respond more quickly to actual client requests. Sometimes." "Sometimes?" "Well, most the time." "Why's that? What's causing the initial latency?" "Cold starts." "Yeah, but what's that mean?" "The machine is booting or caching runtime data or, you know, warming up and serverless. Anyway, don't think about it too much, just trust me on this rock thing. Speaking of which, I got to get back to bastardizing our core logic. Eddie had great results with his new exponential backup rock toss routine and I'm thinking of combining that with a graphql random parameter generator library that Ted said just went alpha this afternoon."
- 9935c101ab17a66 8y ago
  yo can I get a link to that gql random parameter generator library?
- hn_throwaway_99 8y ago
  Exactly - this blog post I've always thought was a great overview: https://hackernoon.com/im-afraid-you-re-thinking-about-aws-lambda-cold-starts-all-wrong-7d907f278a4f https://hackernoon.com/im-afraid-you-re-thinking-about-aws-l...
Cthulhu_ 8y ago
If initial startup time - and long periods of non usage - is an issue, wouldn't a permanently running VPC for the initial load be a better solution?

alexanderdmitri 8y ago

Even if you invoke your lambda function to warm it up in anticipation of traffic, you'll still hit cold starts if the lambda needs to scale out; the new machines are exposed to inputs "cold." Those crazy patterns trying to warm the lambda up are really crazy if you think about it because no one is using them is really aware of the underlying process(es) involved. "Why are you throwing rocks at that machine?" "It makes it respond more quickly to actual client requests. Sometimes." "Sometimes?" "Well, most the time." "Why's that? What's causing the initial latency?" "Cold starts." "Yeah, but what's that mean?" "The machine is booting or caching runtime data or, you know, warming up and serverless. Anyway, don't think about it too much, just trust me on this rock thing. Speaking of which, I got to get back to bastardizing our core logic. Eddie had great results with his new exponential backup rock toss routine and I'm thinking of combining that with a graphql random parameter generator library that Ted said just went alpha this afternoon."

9935c101ab17a66 8y ago
yo can I get a link to that gql random parameter generator library?
hn_throwaway_99 8y ago
Exactly - this blog post I've always thought was a great overview: https://hackernoon.com/im-afraid-you-re-thinking-about-aws-lambda-cold-starts-all-wrong-7d907f278a4f https://hackernoon.com/im-afraid-you-re-thinking-about-aws-l...

Cthulhu_ 8y ago

If initial startup time - and long periods of non usage - is an issue, wouldn't a permanently running VPC for the initial load be a better solution?