I have an ASP.net app running on Azure app service. When the requests go above 1K, the whole site slows down and scaling up from S1 to S2(more RAM,CPU and ACU) resolves the issue.
How can I auto scale-up the service in certain hours like between 17:00 to 21:00 on weekends?
Is there any service in Azure for auto scaling up? I found auto scale-out in Azure but I want to do auto scale up.
Unfortunately there is no built-in Azure WebApp feature to make Azure WebApp scale up.
You can create Azure Function with time trigger or Azure Automation Account that will run in certain hours.
Then write C# or Powershell code that will make Azure WebApp scale up.
Related
I have created 1 node.js and 1 java Azure Function, using VS Code
When I have deployed just these 2 functions to Azure using VS Code, I ended up with this many Azure resources (see the picture below).
Is there a way to re-use the same resource type (i.e. App Service, Storage Account, etc..) to host multiple Azure Functions?
Absolutely, we do this all the time. We usually create resources in the portal by hand the first time and later use deployment scripts (msdeploy or Powershell) to update the resources.
When you create a new Function App in the portal, you can tell Azure to put the new Function App in an existing App Service Plan and also set it to use existing storage:
You can also do this using Azure CLI if you are a CLI guy.
I am in the process of moving multiple websites to Azure under one Premium App Service plan. Following the instructions provided here https://dotnetthoughts.net/deploying-multiple-application-in-webapp/ I was able to host multiple sites under one App Service Plan but I am struggling to figure out how I can make use of Deployment Slots for multiple sites. It looks like there is only one "Production" Slot per App Service plan which means I can only swap a Deployment Slot with the only Production Slot. Does someone know how each website can have a Production Slot and a corresponding "Testing" Slot?
You can have multiple web apps under a single Azure App Service Plan. Meanwhile, under every web app(App Service), you can create multiple slots and you can have production and staging for every web app separately.
Each App Service plan tier supports a different number of deployment slots. Azure App Service Plan Premium (v2) supports = 20 and standard supports = 5 deployment slots.
Based on your requirement you can put all your apps in one App Service plan and have multiple deployment slots. If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances.
Since you pay for the computing resources your App Service plan allocates, you can potentially save money by putting multiple apps into one App Service plan. You can continue to add apps to an existing plan as long as the plan has enough resources to handle the load. However, note that the apps in the same App Service plan all share the same compute resources. Overloading an App Service plan can potentially cause downtime for your new and existing apps.
You don't get charged for using the App Service features that are available to you (configuring custom domains, SSL certificates, deployment slots, backups, etc.)
Checkout this document for more details: https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots
When I configure a new azure bot service application on Azure, it creates it as a consumption pricing tier application. This seems to possibly be causing issues on cold starts where the application takes quite a long time (in comparison to a running application) to respond.
I would like to configure the application to use a resource group that is on an basic plan so that I can make it 'always on'.
Is there a setting I am missing or is this just not possible at this time?
Edit: I am OK with paying for the ability to enable "Always On" like I can with the typical Azure Function/web apps. At this point I do not see a way to configure a bot application to allow it to be anything but a consumption based application.
Edit2: clarified that this is an azure bot service application
Are you creating an SDK bot, or an Azure Bot Service bot? SDK bots are just web applications, and can be in any consumption pricing plan (including Always On): https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure
Azure Bot Service bots are function applications. They should also be provisional within an App Service plan: https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
Edit:
From above documentation: you will need to setup a VM to host an Azure Function as Always On.
App Service plan
In the App Service plan, your function apps run on dedicated VMs on
Basic, Standard, and Premium SKUs, similar to Web Apps. Dedicated VMs
are allocated to your App Service apps, which means the functions host
is always running. Consider an App Service plan in the following
cases: You have existing, underutilized VMs that are already running
other App Service instances. You expect your function apps to run
continuously, or nearly continuously. You need more CPU or memory
options than what is provided on the Consumption plan. You need to run
longer than the maximum execution time allowed on the Consumption
plan. A VM decouples cost from both runtime and memory size. As a
result, you won't pay more than the cost of the VM instance that you
allocate. For details about how the App Service plan works, see the
Azure App Service plans in-depth overview.
I am trying to wrap my head around the concept of Azure App Service plan and Azure App Services, with no luck.
My understanding is that an App Service Plan defines the capacity and the pricing, all apps assigned to a specific App Service plan will share the same resources, is that right?
If that is right, then what is the benefit of the scaling-out? If the scale out will create more instances of the same app which at the end will be hosted on the same App Service Plan (sharing the same resources)?
I read almost all the official and non-official documentation about Azure App Service plan and App Services but couldn't find an answer to this question, they are all saying that scaling is working on the app level (not the app service plan) and at the same time saying that the apps assigned to the same app service plan are actually sharing the same resources, so what is the benefit of the scale-out feature?
Regards,
My understanding is that an App Service Plan defines the capacity and
the pricing, all apps assigned to a specific App Service plan will
share the same resources, is that right?
Yes.
If that is right, then what is the benefit of the scaling-out? If the
scale out will create more instances of the same app which at the end
will be hosted on the same App Service Plan (sharing the same
resources)?
No one forces you to put all your apps on the same App Service Plan. When you create an App you put it into some App Service Plan. All the Apps on that (and only that) App Service Plan would share resources, but you could create a lot of App Service Plans.
Also, when you scale out you create more PaaS instances of the VM's hosting your App, so when you scale out you are not getting another App Pool in the same IIS, you are getting another App Pool on the other IIS on the other VM.
edit: to clarify the comment, the App Service Plan is a collection of Windows VM's with IIS installed on them. All the Apps assigned to that App Service Plan are hosted on ALL the instances of those VM's, when you scale out or scale up you change the number or capacity of those VM's.
There's no temporary App Service Plan. You pay for the Service Plan, not for the App. Apps cost nothing, they are simply consuming resources on the Service Plan, its the Service Plan that "eats" money. You are getting billed according to the Service Plan tier and scale.
Pricing is based on the size and number of VM instances you run.
As I know, the scale out would create multiple copies of your web app and add a Load Balance to distribute the requests between them automatically. And you don't need to configure the load balance separately by yourself.
Assuming that you create a website (a windows server with IIS), then your website would has the App Pool which defines the available resources for your website. Each instance could handle a limited number of requests, in order to reduce the response time, you could scale out your website into multiple instances, then each web-server could split the work load. For more details, you could refer to Scaling Up and Scaling Out in Windows Azure Web Sites and this tutorial for a better understanding of Azure Web App auto scale.
As #4c74356b41 said when you scale out you are going to get more physical resources (i.e VM's with more compute, memory and storage). Also one correction as per Azure documentation, scale out is going to effect all apps in app service plan. see below link and the point to note is
"The scale settings take only seconds to apply and affect all apps in your App Service plan. They do not require you to change your code or redeploy your application" -
https://azure.microsoft.com/en-us/documentation/articles/web-sites-scale/
The docs answer this clearly: https://learn.microsoft.com/en-us/azure/app-service/overview-hosting-plans#how-does-my-app-run-and-scale
In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.
I'm moving 10 sites to Azure Website(s), they need to use Classic Application Pipeline, not integrated.
How can I set that?
Currently - you cannot modify any application pool settings of Azure Websites for any Mode (Free, Shared, or Reserved). There are few configuration settings you can control for Azure Websites.
You will need to either use an Azure VM or Azure Web Role.