5 ms·

Have you tried provision concurrency[1], this along with ARM based functions can help you with performance and reduce costs. 1 - https://aws.amazon.com/blogs/a

by websap 5y ago

Have you tried provision concurrency[1], this along with ARM based functions can help you with performance and reduce costs. 1 - https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/ https://aws.amazon.com/blogs/aws/new-provisioned-concurrency...

015a 5y ago
Provisioned concurrency is a bit of a non-starter for cold start latency reduction in user-facing applications. Its a tool in the toolbox, but the problem is: Let's say you set the provisioned concurrency at 10, then you have 11 concurrent requests come in. That 11th request will still get a cold start. PC doesn't scale automatically. The ping architecture of warming up functions does scale (better) in this setup. Its not perfect, but nothing on lambda is; its possible that the ping request for User2 could get routed to a live function, which finishes, then starts handling a real request for User1, User2's real request comes in but this function is busy, so Lambda cold starts another one. That being said, these ping functions can be cheap relative to PC. PC is not cheap; its ~$10/mo/gb/function. With the ping architecture; you'd generally just invoke then immediately exit, so there's very little billed execution time. For sparsely executed functions, the ping architecture is better because PC is billed 24/7/365, whereas ping is billed per invoke (that being said: PC is a much cleaner solution). For high volume functions, PC may be cheaper, but it also won't work as well; if your concurrent executions are pretty stable, then its a great choice, but if its spiky high volume (as most setups are!) then it's hard to find a number which balances both cost and efficacy. A setup which also includes Application Autoscaling, to automatically adjust the PC level with time of day or system load or whatever, would approach a better setup. But, of course, be more work. The other frustrating thing about PC is its price relative to a cloudwatch events cron warming setup. Most sources say Lambdas stay warm for ~5 minutes, which means you only need ~15,000 invocations/month per "faux-Provisioned Concurrency" level. Theorycrafting at 100ms/invocation and 512mb: that's ~$0.012/month. PC is ~500 times more expensive than this. This kind of cron-based ping setup is very easy when PC=1; at 1+, it gets harder, but not impossible: You have a cron configured to execute a "proxy" lambda, which then concurrently invokes the real lambda N times depending on what level of PC you more-or-less want. It's also worth noting that PC cannot be maintained on the $LATEST function version. It can only be maintained on an explicit Function Version or Alias (which does not point to $LATEST). So there's just more management overhead there; you can't just have a CI deploy functions and let AWS do everything else, you have to configure the CI to publish new versions, delete the existing PC config, and create a new PC config, maybe also adjust autoscaling settings as well if you configured it. All automatable, but definitely in the domain of "CloudOps Engineer Job Security"; anyone who tells you AWS will make your life easier is probably working for AWS.
- websap 5y ago
  At least in the OP’s case it seems the requests are infrequent. I understand your point about the 11th request, but at that point what % of your customers are impacted. The tail latency is always an issue, PC is a good way to solve that.
  - 015a 5y ago
    Yeah, I'd say it just depends on your needs. PC is definitely "better". It does require you to opt-in to function versioning, but if your ops automation is good enough to make that easy, its just better. The biggest advantage over warming pings is, really, that it keeps your metrics and logs clean and focused just on user invocations, not on weird faux-invokes that are extremely difficult to filter out. But, its downside is that its ~100x more expensive than warming pings for infrequently invoked functions (defined as: average concurrent invocations over a month timeframe between 0 and 1). If your company has the money, go for PC. But don't feel bad about going for warming pings; it ain't a bad setup at all.
- WatchDog 5y ago
  Hit the nail on the head with this one. The pinging approach incredibly more cost-effective than provisioned concurrency.
gunnarmorling 5y ago
PC doesn't make that much sense for a use case like mine, where absolute cost minimization is the goal. My request volume (including ping requests) easily fits into the Lambda free tier, whereas with PC I'd be looking at some cost. More generally, I feel PC kinda defeats the purpose of Lambda to begin with. If I'm in that range of continuous load, I'd rather look at more traditional means of provisioning and hosting this application.
- websap 5y ago
  PC is a good way to keep certain amount of performance guarantees. It seems like you’re solution fits into the free tier, so probably a bad idea for you.
- zxcvbn4038 5y ago
  I think you are thinking of reserved concurrency - with reserved concurrency you can only run as many instances as you have reserved. With provisioned concurrency you can run as many as your quota allows but you are guaranteed to be able to handle as many concurrent instances have provisioned. Neither one of these are going to help you with cold start times, it is not defining the number of instances running, its just reserving a portion of quota so that they can run. Where provisioned/reserved concurrency comes in useful is keeping a run-away lambda function from starving out other functions either by guaranteeing a portion of the quota for the other functions or keeping a function from exceeding a number of concurrent executions. The "ping" technique you mentioned is one way to keep a function warm but if lambda decides to start a second instance of the function because the hot one is handling a request, then that person is going to take a warm up hit and nothing you can do about that. If you are really latency sensitive then lambda might not be the right choice for you. You can get a t4g.nano SPOT instance for about $3.50/month and you can keep that warm, but that is probably a whole lot more then you are paying for lambda.
  - gjhr 5y ago
    Provisioned concurreny does decrease cold starts. Reserved concurrency both guarantees a portion of your concurrency limit be allocated to a lambda as well as capping concurrency of that lambda to that portion. Reserved concurrency has no cost associated. Provisioned concurrency keeps a certain number of execution environments warm for your use. Provisioned concurrency costs money.

by websap 5y ago

015a 5y ago

Provisioned concurrency is a bit of a non-starter for cold start latency reduction in user-facing applications. Its a tool in the toolbox, but the problem is: Let's say you set the provisioned concurrency at 10, then you have 11 concurrent requests come in. That 11th request will still get a cold start. PC doesn't scale automatically. The ping architecture of warming up functions does scale (better) in this setup. Its not perfect, but nothing on lambda is; its possible that the ping request for User2 could get routed to a live function, which finishes, then starts handling a real request for User1, User2's real request comes in but this function is busy, so Lambda cold starts another one. That being said, these ping functions can be cheap relative to PC. PC is not cheap; its ~$10/mo/gb/function. With the ping architecture; you'd generally just invoke then immediately exit, so there's very little billed execution time. For sparsely executed functions, the ping architecture is better because PC is billed 24/7/365, whereas ping is billed per invoke (that being said: PC is a much cleaner solution). For high volume functions, PC may be cheaper, but it also won't work as well; if your concurrent executions are pretty stable, then its a great choice, but if its spiky high volume (as most setups are!) then it's hard to find a number which balances both cost and efficacy. A setup which also includes Application Autoscaling, to automatically adjust the PC level with time of day or system load or whatever, would approach a better setup. But, of course, be more work. The other frustrating thing about PC is its price relative to a cloudwatch events cron warming setup. Most sources say Lambdas stay warm for ~5 minutes, which means you only need ~15,000 invocations/month per "faux-Provisioned Concurrency" level. Theorycrafting at 100ms/invocation and 512mb: that's ~$0.012/month. PC is ~500 times more expensive than this. This kind of cron-based ping setup is very easy when PC=1; at 1+, it gets harder, but not impossible: You have a cron configured to execute a "proxy" lambda, which then concurrently invokes the real lambda N times depending on what level of PC you more-or-less want. It's also worth noting that PC cannot be maintained on the $LATEST function version. It can only be maintained on an explicit Function Version or Alias (which does not point to $LATEST). So there's just more management overhead there; you can't just have a CI deploy functions and let AWS do everything else, you have to configure the CI to publish new versions, delete the existing PC config, and create a new PC config, maybe also adjust autoscaling settings as well if you configured it. All automatable, but definitely in the domain of "CloudOps Engineer Job Security"; anyone who tells you AWS will make your life easier is probably working for AWS.

websap 5y ago
At least in the OP’s case it seems the requests are infrequent. I understand your point about the 11th request, but at that point what % of your customers are impacted. The tail latency is always an issue, PC is a good way to solve that.
- 015a 5y ago
  Yeah, I'd say it just depends on your needs. PC is definitely "better". It does require you to opt-in to function versioning, but if your ops automation is good enough to make that easy, its just better. The biggest advantage over warming pings is, really, that it keeps your metrics and logs clean and focused just on user invocations, not on weird faux-invokes that are extremely difficult to filter out. But, its downside is that its ~100x more expensive than warming pings for infrequently invoked functions (defined as: average concurrent invocations over a month timeframe between 0 and 1). If your company has the money, go for PC. But don't feel bad about going for warming pings; it ain't a bad setup at all.
WatchDog 5y ago
Hit the nail on the head with this one. The pinging approach incredibly more cost-effective than provisioned concurrency.

gunnarmorling 5y ago

PC doesn't make that much sense for a use case like mine, where absolute cost minimization is the goal. My request volume (including ping requests) easily fits into the Lambda free tier, whereas with PC I'd be looking at some cost. More generally, I feel PC kinda defeats the purpose of Lambda to begin with. If I'm in that range of continuous load, I'd rather look at more traditional means of provisioning and hosting this application.

websap 5y ago
PC is a good way to keep certain amount of performance guarantees. It seems like you’re solution fits into the free tier, so probably a bad idea for you.
zxcvbn4038 5y ago
I think you are thinking of reserved concurrency - with reserved concurrency you can only run as many instances as you have reserved. With provisioned concurrency you can run as many as your quota allows but you are guaranteed to be able to handle as many concurrent instances have provisioned. Neither one of these are going to help you with cold start times, it is not defining the number of instances running, its just reserving a portion of quota so that they can run. Where provisioned/reserved concurrency comes in useful is keeping a run-away lambda function from starving out other functions either by guaranteeing a portion of the quota for the other functions or keeping a function from exceeding a number of concurrent executions. The "ping" technique you mentioned is one way to keep a function warm but if lambda decides to start a second instance of the function because the hot one is handling a request, then that person is going to take a warm up hit and nothing you can do about that. If you are really latency sensitive then lambda might not be the right choice for you. You can get a t4g.nano SPOT instance for about $3.50/month and you can keep that warm, but that is probably a whole lot more then you are paying for lambda.
- gjhr 5y ago
  Provisioned concurreny does decrease cold starts. Reserved concurrency both guarantees a portion of your concurrency limit be allocated to a lambda as well as capping concurrency of that lambda to that portion. Reserved concurrency has no cost associated. Provisioned concurrency keeps a certain number of execution environments warm for your use. Provisioned concurrency costs money.