I think the cold start problem has already been mentioned.
Other than paying more (App Service plan or Premium plan), one other option is to write a little more code to save a bunch of money.
- Add a new query param
?keepWarm=1
to your REST API endpoint you want to keep warm. Implementation of this function would be to return 200 if it's a keepWarm
call.
- Add a scheduled function (timer-trigger) that wakes up every X seconds, makes a call to
/endpoint?keepWarm=1
Host this whole thing in consumption plan.
Even for X = 1 second
, you'll probably end up paying a LOT less ($5-20) than other expensive plans ($100+ I think).
IMHO Premium and Dedicated plans are when you need more fire-power, not when you want to keep things warm. In fact Consumption plan would let you scale to 200 instances whereas the limit for other pricey plans is 10 to 100.
With pricey plans you do get more fire-power so you can do bigger tasks and take as long as you like:
- 210-840 ACU
- 1.75-14GB RAM
- unbounded execution time limit (#)
($) unbounded execution time limit: If your trigger is HTTP Trigger (REST API) then this is useless due to load balancer limitation
If a function that uses the HTTP trigger doesn't complete within 230 seconds, the Azure Load Balancer will time out and return an HTTP 502 error. The function will continue running but will be unable to return an HTTP response.
On unit of scaling:
This is very unclear.
Scaling Function App instances
As described here.
In the Consumption and Premium plans, Azure Functions scales CPU and memory resources by adding additional instances of the Functions host. The number of instances is determined on the number of events that trigger a function.
Each instance of the Functions host in the Consumption plan is limited to 1.5 GB of memory and one CPU. An instance of the host is the entire function app, meaning all functions within a function app share resource within an instance and scale at the same time.
- What's clear is
- that when AFR (Azure Function Runtime) figures out that there is need to scale (based on traffic) it will spawn new Function Host(s), each Host contains the whole Function App along with all it's Functions.
- you as a developer must create your functions in such a way that they limit their resource usage to what one Function Host offers.
- What's NOT clear is
- whether each Host would have only one instance of each Function, or multiple.
- whether multiple different Functions within same App be executed in parallel or not. If yes, then each Function implementation needs to share Host resources with other Functions that co-exist in this App.
Scaling worker processes
Also it is possible to set FUNCTIONS_WORKER_PROCESS_COUNT
to control number of language worker processes
via Application Settings.
I guess in this case each language worker process would run within same host and would share resources.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…