Sorry for the stupid question, I genuinely want to know: how does this differ from firing up your function with an additional call every, idk, 5 mins? Wouldn’t it be cheaper and easier?
This works beyond a scale of 1, e.g if you want to be ready for 100 concurrent invocations using ping it’s quite difficult to do that I imagine.
Also presumably more reliable.
With the 5 minute ping the underlying container will be reprovisioned every few hours. At which point it’s a race to see whether the next ping comes before the real user request to swallow the cold start.
And what if I fire 500 concurrent keep-alive's? (Or maybe a bit of overhead). Then the 500 lambda instances will stay alive for a couple of minutes again, but I'm still only charged the 500 calls. Not the Gb/sec the rest of the time the labmda's are alive, right?
How do you ensure that the 500 concurrent keep-alives land on different Lambda functions? I.e. requests 220 and onwards might hit lambda functions which were warmed up by requests 0-219. I just made the above numbers up of course.
That's why I mentioned 'with maybe some overhead'. You can also have the keep-alive handling take a second or 2 extra to complete, to have the lambda blocked for this time, so the burst calls get more spread.
It's not going to be a precise solution, but still, paying 2-3 seconds every minute instead of paying the whole minute is still a lot cheaper.
Comments
Sorry for the stupid question, I genuinely want to know: how does this differ from firing up your function with an additional call every, idk, 5 mins? Wouldn’t it be cheaper and easier?
This works beyond a scale of 1, e.g if you want to be ready for 100 concurrent invocations using ping it’s quite difficult to do that I imagine.
Also presumably more reliable. With the 5 minute ping the underlying container will be reprovisioned every few hours. At which point it’s a race to see whether the next ping comes before the real user request to swallow the cold start.
And what if I fire 500 concurrent keep-alive's? (Or maybe a bit of overhead). Then the 500 lambda instances will stay alive for a couple of minutes again, but I'm still only charged the 500 calls. Not the Gb/sec the rest of the time the labmda's are alive, right?
How do you ensure that the 500 concurrent keep-alives land on different Lambda functions? I.e. requests 220 and onwards might hit lambda functions which were warmed up by requests 0-219. I just made the above numbers up of course.
That's why I mentioned 'with maybe some overhead'. You can also have the keep-alive handling take a second or 2 extra to complete, to have the lambda blocked for this time, so the burst calls get more spread. It's not going to be a precise solution, but still, paying 2-3 seconds every minute instead of paying the whole minute is still a lot cheaper.
Ok, I quickly did the math for 500 lambdas (1Gb):
Provisioned: 500 * 86400 (sec/day) * 0.000004167 ~= $180
Keep-alive: 500 * 1440 (min/day) * 2 (sec. runtime) * 0.000016667 (100ms price) * 10 ~= $240
Invocation costs on the provisioned ones would be a lot cheaper too cheaper too. Roughly $45 provisioned vs $80 for 50M calls.
So depending on the demands, provisioning can be more performant, and cheaper at the same time.