I have one Application Service Plan. Premium Tier. 3 Functions Apps. 3 application insights.
For ASP settings for every function app I have this settings
what does mean this number of servers when I open stream in application insights?
when I dont have any jobs to execute in any functions I see that number of servers is 2 for every function app. If some function does some jobs I see more servers allocated for this function. As I understand when no jobs, 2 servers means 1 mandatory instance + 1 always ready.As as I see the same servers allocated for all 3 functions apps. Does it means that "server" it is not the same as "function app" object?
You are right. Since all your function apps are using the same App Service plan, they will share the server instances pool. As you have understood, there will be 2 active servers if your function app was in active use with some workload. If the load increases, Azure would assign work to the pre-warmed instance and create 1 more 'Always ready' instance. Unless you have set the Maximum burst limit for the App Service Plan, or the Max scale out limit for any of the Function app, Azure will keep adding VM instances to the server pool as workload increases.
Related
We have a solution where we use an Azure Storage Queue to process messages that take approx 6 minutes.
I've read that the maximum batchSize of Queue messages concurrently processed are 32 per VM.
If the function app scales out to multiple VMs, each VM could run one instance of each queue-triggered function.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-storage-queue?tabs=in-process%2Cextensionv5%2Cextensionv3&pivots=programming-language-csharp#host-json
How does that translate to Azure Functions Premium plan?
Lets say we want to be able to process 64 messages at once using Azure Functions Premium plan with Always ready instances. If we have 2 ready instances, can they process 2 * 32 concurrent messages? Or do they underwater really need to be on seperate VM's and 2 instances will not do anything different?
In the Premium plan, you can have your app always ready on a specified number of instances. The maximum number of always ready instances is 20. When events begin to trigger the app, they are first routed to the always ready instances.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal#always-ready-instances
Yes. In Azure Functions premium plan, if you have pre-warmed instance, then that is given a dedicated VM instance. So, if you had 2 VM instances running your function app, then they can process 2*(batchSize + newBatchThreshold) concurrent Queue messages!
The Azure platform scales the function app onto new VM as the existing instances gets more busy.
I have a durable function app to handle xml file in blob which size is between a few megabytes and hundreds of megabytes.
The requirement requires up to 20 files to be process at the same time.
I've scaled out the durable function app to 4 instances, but when requests increase rapidly, only 2 instances encountered the problem of too high CPU, while the other 2 did not.
This results in very slow file processing.
Is there a problem with azure's built-in load balance?
See this picture to check the high CPU issue
Generally, the scaling logic in Azure Functions currently works well when the function is triggered by things like queues or Event Hubs.
if you're running your Function in an App Service (also known as a Dedicated Plan), it will by default only scale instances within the possibilities of the App Service Plan you defined.
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. [...] You can also scale up by choosing a different App Service plan.
If you run your Function App on Consumption Plan (the true serverless hosting plan option since it enables scaling to zero)
For further information check the below provided links.
Azure Functions Scalability Issue.
Azure Functions Hosting Plan.
Consumption Plan Scaling Issues.
I am using Azure Functions on the App Service Plan. My understanding is for every new execution the Azure Function will create a new App Service, execute the function and then shut down the App Service. There would be nothing shared between the multiple App Services that are spawned due to multiple requests.
However when I do test my Function(which is a video processing one), for one request the time it takes is around 2-3 mins however for multiple simultaneous requests the time increases to 10-15 mins. My questions are whether my understanding above is correct? If not then what resource is shared amongst these App Services? How should I decide my scaling options(manual vs auto)?
"My understanding is for every new execution the Azure Function will create a new App Service" Nope it will not run new instance each time. Generally if there is no load on AF it will stop all instances.
Then if first request/event comes in it will start first instance. This is why we have ColdStart in Serverless. After that scale controller will measure your instance performance memory and CPU consumption and decide if it needs to scale but it wont be instant. So if lets say you sent N amount of requests to do smth with video they could go to same first instance and increase load. Then AF will scale, because of CPU spike but it wont help with old requests since they are handled at first instance. Keep in mind For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds which means that your AF should have CPU spike for at least 30 second to add new instance https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling
I am not sure if Azure Functions are good option for video processing. Azure function should be used for quick stuff usually I would say not more than 30 sec. But there are some limitation of execution time depends how you run it https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal
Not sure what type of video processing you doing but i would have a look into Azure Media Services
The other options as you mentioned is Batch jobs with low priority https://azure.microsoft.com/en-au/blog/announcing-public-preview-of-azure-batch-low-priority-vms/ it actually a good use case you have: Media processing and transcoding, rendering and so on
A small addition to Vova's answer: if you're running your Function in an App Service (also known as a Dedicated Plan), it will by default only scale instances within the possibilities of the App Service Plan you defined. This means that all of the instances of your Function App run on the same virtual machine. That is most probably the reason you're seeing increasing request times with more requests.
If you want your Functions to scale beyond the capabilities of that plan, you will need to manually scale or enable autoscaling for the App Service plan.
An App Service plan defines a set of compute resources for an app to run. These compute resources are analogous to the server farm in conventional hosting.
and
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. [...] You can also scale up by choosing a different App Service plan.
If you run your Function App on Consumption Plan (the true serverless hosting plan option since it enables scaling to zero),
The Consumption plan scales automatically, even during periods of high load.
In case you need longer execution times than those available in Consumption Plan, but the App Service Plan doesn't seem to be the best hosting environment for your Functions there's also the Premium Plan.
The Azure Functions Elastic Premium plan is a dynamic scale hosting option for function apps.
Premium plan hosting provides the following benefits to your functions:
Avoid cold starts with perpetually warm instances
Virtual network connectivity.
Unlimited execution duration, with 60 minutes guaranteed.
Premium instance sizes: one core, two core, and four core instances.
More predictable pricing, compared with the Consumption plan.
High-density app allocation for plans with multiple function apps.
More info on all the different Azure Functions hosting options.
I am trying to understand the azure service plan and how it effect our project's budget.
To give some background, we have two web applications running under Azure Cloud services in single instance auth.foo.com and api.foo.com. This was a good and convenient way to save some money as you still have to pay for one cloud service. We were doing this using hostheaders to deploy two apps on a same IIS instance.
With new WebApp model I understand we can not do the same thing.
Enter the app service plan. I understand its a grouping mechanism to group your apps so that they can be under one roof. The thing I am not clear about is how its billed? So If I have both apps under a same app service plan does it mean I get billed for two apps or just for one?
Think of an App Service Plan as a mapping from sites to servers. So you can have a large amount of small apps running on a couple of servers, or a small amount of large apps running on the same couple of servers. Provided that your App Service Plan is the same SKU and there are the same amount of instances in each, these will be the same cost.
That's why the billing page: https://azure.microsoft.com/en-us/pricing/details/app-service/plans/ has unlimited for the number of web apps. So to answer your question specifically, you will get billed for one App Service Plan regardless of the number of apps you have in it, since regardless of the number of apps, you'll be using the same amount of servers.
I have an Azure Application Service Environment.
Is it okay to have multiple App Service Plans (Dev,Test, and Production) all running in the same ASE?
Basically, I know they'll share the Front End Pool, which I'm assuming is fine because no app code is running there and it "...contains compute resources responsible for SSL termination as well automatic load balancing of app requests within an App Service Environment. "
I guess my confusion is around the Worker Pools and Instances.
If I have a Dev Test and Prod can I host each one in a Different Worker Pool? Or would I even need to, could I just host them all in the same worker pool but they'd be using different instances so they're separated? Would I need 2 Worker Pool Instances per App Service Plan to make sure I have redundancy? (Confused why the Website says you only need one additional Instance (for 1-20 instances).
Basically, is this okay? And if so, what would the worker pool setup look like?
Would I have 6 instances in 1 pool with auto-scale turned on?
2 Instances in each of the separate 3 pools with auto-scale turned on?
Or would I need 3 separate Application Service Environments?
I've spent the last 2 hours reading Microsoft articles but none speak clearly about this or have a real-world example setup.
The documentation clarity regarding ASEs is still very much a problem. This is troublesome as ASEs are sold as a premium integrated hosting product in Azure.
I have had a discussion with an engineer at Microsoft about this very question and I still cannot say I understand the resource enough to be happy. Here is what I understand:
An ASE comes with 3 worker pools (vm) by default
All worker pools run the applications defined in your worker pool 1
You can define a different set of ASP and Applications for your worker pool 3 for example and have production on 1 & 2 and dev on 3.
Instances in a worker pool affect all the applications of your configuration.
The way I see it ASE is designed for a very specific business scenario that I have yet to see. It is quite powerful but you will most likely never use it to it's potential. I guess that's why Microsoft engineers recommend using simple App Services in most scenarios.