Reputation: 905
By creating Azure function app service under consumption plan with single HTTP trigger function in it, can I control that Azure function app service number of instances serving the incoming request? If yes, how to control app service instance?
If no, what is rationale behind Azure scaling or instantiation logic? If I have singleton static resource like cosmos db connection how it can be shared across the azure function app service instances? to improve performance.
Upvotes: 1
Views: 1615
Reputation: 7696
You cannot determine how the Azure Scale Controller will scale out additional instances of your HTTP-triggered function in the Consumption or Premium plans. The Scale Controller will make its best guess on when additional instances of your function should be provisioned.
Also note that if you went from a cold start to "Everyone on Reddit is requesting my function RIGHT NOW", the Azure Scale Controller is throttled to adding a new instance of your HTTP triggered function to at most one per second. I've run into this one the hard way as the HTTP queue deepens for sudden torrents of traffic.
Also, when your function is scaled out, you have no control in the Consumption and Premium plans on what VM within your region that new instances will be added to. Singleton variables within your Azure Function will only be shared by function instances within the same VM. Plan accordingly. The only way around this behavior is to host your Azure Function on an App Service plan. With this scenario, you KNOW that your Azure Function will be running on the same N VM instances, where N is the number of scaled-out Web App instances.
Upvotes: 1