Actually I am getting System.OutOfMemoryException for blob trigger azure function.Do i need to scale up or Scale out App Service Plan to fix this problem.
What is the difference between these two?
For your original question, if your function is running on consumption plan, Scale up App Service Plan of your Azure service.The plan you already have less Memory and if you have multiple functions running in App Service Plan then scale out.
From the docs,
Scale up means :
A scale up operation is the Azure Web Sites cloud equivalent of moving
your non-cloud web site to a bigger physical server. So, scale up
operations are useful to consider when your site is hitting a quota,
signaling that you are outgrowing your existing mode or options. In
addition, scaling up can be done on virtually any site without
worrying about the implications of multi-instances data consistency.
Two examples of scale up operations in Windows Azure Web Sites are:
Scale Out means:
A scale out operation is the equivalent of creating multiple copies of
your web site and adding a load balancer to distribute the demand
between them. When you scale out a web site in Windows Azure Web Sites
there is no need to configure load balancing separately since this is
already provided by the platform.
Digram depicting the difference between the two :
You need to scale up your app service plan.
"Scale up" means upgrade the capacity of the host where the app is hosted. Ex: Increase the memory from 1.75GB to 3.5GB.
"Scale out" means upgrade the capacity of the app by increasing the number of host instances.
In Short Scale Up is vertical scaling, where you add more resources to increase capacity of the underlaying Hardware/Infrastructure.
Where, Scale Out is horizontal scaling, where you add more instance of the same app to process/handle request simultaneously.
If you choose Scale Out, you will get more VMs and balance your workloads to those VMs. If you choose Scale Up, your VM will get more punch to handle current workloads. More VMs or more power to your current VM
Related
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.
Context: I am designing the auto-scaling (scale out) configuration for my .NET Framework 4.7 web app hosted on a Microsoft Azure App Service. I am using the P3V2 pricing tier. The application is CPU-bound. The app's 30 day CPU average is 30% usage while running on 2 instances, according to the stats indicated in the App Service plan. We occasionally have traffic spikes which will overwhelm the 2 instances: I want to implement auto-scaling.
I want to take into account the App Service Provisioning + App Startup Time when designing the metrics thresholds that decide when my app service scales out. I need to make my thresholds low enough to give Azure time to spin up a new app service instance but not so low that I am paying unnecessarily for processing power that's not needed. Budget is a significant factor.
Question: How long does it take for an Azure App Service instance to be available after a scale out? In other words, how long does it take for an Azure App Service to scale out?
P.S. I recognize that there is a lot more to scaling in/out that I am not addressing here. I'm trying my best to be succinct. :)
Generally, not long at all. By that I mean typically under one minute, but the time will vary depending on several factors, such as application size, time of day, region of deployment.
You could scale out manually and inspect the run history logs on the scale out tab.
FYI you can also use Azure Monitor to create auto-scale policies, in case this is of any use to you.
I am running an optimization model (using Google.OrTools) that I build in .Net framework. When I run in my local, the application was running with a CPU of more than 99%, so my team has decided to move this application to Azure ScaleSet where I have one VM and I configured to Scale up to 10 VMs. The problem I face is the same >99% CPU only in my main VM even though new VMs have been added (scaled-up), the CPU on that VMs are <1%. I am now confused about working with ScaleSets in Azure.
In my above case, I am thinking that the job has not been shared with other VMs. How can I resolve this?
Please note that I am running my application using a Console Application and this job does not have frequent connections with database and also Drive, this job is a purely mathematical problem.
Customer will use Azure VMSS as the front endpoint(Or backend pool).
Azure VMSS autoscale ability reduces the management overhead to monitor and tune your scale set as customer demand changes over time.
Azure VMSS will use Azure load balancer to route traffic to all VMSS instances, in this way, all instances CPU usage are consistent.
If your service running without other requests, or other connections, the CPU usage is 99%, it means you should resize that VM to a high size.
First, your preferences and your budget don't determine whether your workload can scale out rather than scale up.
An Azure scale set includes some backend VMs and a load balancer. The load balancer distributes requests to the backend servers.
Your workload can take advantage of an Azure scale set if it consists of multiple, independent requests. The canonical example of this kind of workload is a web server. Running this kind of workload on an Azure scale set doesn't usually require any changes to code.
You might be able to run your workload on a scale set if you have a single request that can be broken down into smaller pieces that can be processed independently. For this kind of parallel processing to work, you'd probably have to rewrite some of your code. The load balancer would see these smaller pieces as multiple requests.
Other ways to improve mathematical performance include
using a different, more appropriate language,
running your code on a GPU rather than a CPU, or
leveraging a third-party system, like Wolfram Mathematica.
I'm sure there are other ways.
Imagine you have 10 physical machines in the lab. How would you split up this task to run faster, on all the machines?
A scale set is a collection of VMs. To make use of scale sets, and autoscale, your compute intensive job needs to be parallelizable. For example, if you can split it into many sub-tasks, then each VM in the scale set can request a sub-task, compute it, send the result somewhere for aggregation, and request another task.
Here is an example of a compute intensive task running on 1000 VMs in a scale set: https://techcommunity.microsoft.com/t5/Microsoft-Ignite-Content-2017/The-journey-to-provision-and-manage-a-thousand-VM-application/td-p/99113
Background
Our company designs and hosts websites for approx. 500 clients, each client has one website. Each website is built on ASP.net. Our current hosting infrastructure is built on hypervisors with virtual machines running Windows. We have 3 virtual machines all running the same spec (8 cores, 24 GB RAM). The 500 client sites are split over these three web servers, there is no load balancing or fault tolerance – the website exists in only one location.
Therefore, as we accumulate clients each web server’s site count increases. When we max out each server, we bring another one online and start again, then once that one is full we spin another VM up etc.
Goal
We would like to move (eventually) our sites over to Azure, however we do not want to replicate our current set up on Azure, instead we would like to move each website over to Azure Web app instead to take advantage of scaling.
We would also like more fine-grained control over our costs when bringing online additional sites. Currently, we bring online a VM and costs us X (for an empty server), it may take us 3 months to fill this. We would like to steadily add to our hosting hosts, not in big steps.
My question
I have investigated for many days on this and cannot find a tutorial or guide on what the ideal set up looks like on Azure Web apps when hosting 100’s of websites. Almost all tutorials assume you only ever going to have one website, so there is a 1:1 relationship between a site and the underlying resource. They never talk about how you should organise your apps into App Service Plans etc.
I understand the concept of adding a website, choosing the appropriate pricing tier and setting the scale settings, what I do not understand is why people online talk about scaling out Azure Apps – surely if an ASP.net websites consumes a certain amount of RAM on a system, by bringing online another VM all you are doing is immediately consuming that amount of RAM again on another system. So scaling out in this sense is to ONLY improve availability – is this correct?
If someone is able to provide some of their own experiences when dealing with a lot of websites on Azure (even better if they own a web design company who hosts on Azure) it would be very much appreciated.
Think of AppService plan as a VM or pool of VMs (in case you run multiple instances) that runs the same applications simultaneously and share the same data disc. If you scale out, you add a new VM to the pool, if you scale up, you change the size of VMs (actually they aren't VMs, but from the user's point of view it is simmilar).
So basically in case like yours, where you run many applications (potentially) smaller applications, scaling up/down establishes the baseline - how many websites you can run, how many applications you can fit in the memory. And then scaling out gives your better reliability and more CPU power that helps you to cope with high traffic.
Our company is much smaller than yours, we host dozens of websites not hundreds. But there are some points that our experience have taught us:
Use at least S2 instances that have 2 cores, with S1 instances a single app can easily degrade performance of other apps in the same AppService plan
Use TrafficManager. If a need arises (e.g. an outage of the service in your region), you can easily move to another region
Split webistes between more smaller AppService plans and collocate applications with the similar usage patterns to the AppService plans. That way you can run one instance, when the traffic is low and spin up new instances when the traffic spikes up.
You are correct that in all pricing tiers (except free and shared) web apps are scaled to all machines in an app service plan. This is an availability feature from the perspective of a web app. Scaling an app service plan from 1 to 2 machines(or auto-scaling) essentially provisions the same web app on all the machines. This of course is no good for your situation, but all is not lost. Generally, the unit of scaling is the app service plan. You could break down web apps into buckets of app service plans. Say first 100+ web apps in AppServicePlan1, then roll over to the next 100+ in AppServicePlan2. The downside is that you will have to manage tracking what app service plan to place the next web app in.
How to autoscale virtual machines(IaaS approach) in azure instead of web/worker role autoscaling in azure?
You can now Autoscale Virtual machines in Azure directly in the Azure Management Portal. ScottGu has a post about it on his blog.
The important thing to autoscale VM's is you must proactively provision the Max # of VM's you think you'll need to handle your peak capacity, and add them to the same availability set.
For example, if on the busiest day of the week it takes 6 machines to handle all of your traffic, then you need to create 6 instances and install your application on it, configure it to handle traffic etc.... and then add it to an availability set with the other 5 machines.
Once you've done this, you can navigate to the Cloud Service that contains all of your virtual machines and click on the Scale tab. You should see a list of your availability sets, and it should tell you the # of machines you can scale over. Choose a metric (either CPU or Queue today), and then range of machines you want to scale between. You can scale between 1 and the total # of machines.
When load is low -- Azure will turn off machines (so you don't have to pay for them), and when load is high, Azure will turn those machines back on.
Auto-scaling on the IaaS level doesn't really make sense. Even if azure could detect high CPU usage and start a new VM based on it, what then? you still need to install your application on that VM automatically somehow.
What you are looking for is something that runs your app on azure, and installs new instances on new VM's if necessary. That "something" is called PaaS enabler. Basically it is another abstraction level between your app and the azure IaaS.
there are a couple of them out there :
Cloudify, CloudFoundary, Juju
as far as i know, only one that supports Azure is Cloudify. you can check out how to configure azure using Cloudify here : Configuring Azure
you can also check out the community - Cloudify Forum, or post questions here for assistance.
Disclaimer: I work for Gigaspaces, developing the Cloudify product line.
According to this it's possible to scale out IaaS with Availability sets by pre-provisioning the number of boxes: https://blogs.msdn.microsoft.com/kaevans/2015/02/20/autoscaling-azurevirtual-machines/