I have my website (abc.azurewebsites.net) hosted to Azure Web Apps using Visual Studio.
Now after 1 month I am facing problems with traffic management. My CPU is always 90 - 95% as the number of requests is too high.
Does anyone know how to add Traffic Management in this web app without changing the domain abc.azurewebsites.net? Is it hard coded in my application?
I thought of changing the web app to a Virtual Machine but now as it's already deployed I am scared of domain loss.
When you Scale your Web App you add instances of your current pricing tier and Azure deploys your Web App package to each of them.
There's a Load Balancer over all your instances, so, traffic is automatically load balanced between them. You shouldn't need a Virtual Machine for this and you don't need to configure any extra Traffic Manager.
I can vouch that my company is using Azure Web Apps to manage more than 1000 concurrent users making thousands of requests with just 2-3 instances. It all depends on what your application does and what other resources does it access too, if you implemented or not a caching strategy and what kind of data storage you are using.
High CPU does not always mean high traffic, it's a mix of CPU and Http Queue Length that gives you an idea of how well your instances are handling traffic.
Your solution might implementing a group of things:
Performance tweak your application
Add caching strategies (distributed cache like Azure Redis is a good option)
Increase Web App instances by configuring Auto-Scaling based on HTTP Queue Length / CPU.
You should not have to change your domain to autoscale a Web App, but you may have to change your pricing tier. Scaling to multiple instance is available at Basic pricing tier, and autoscaling starts at Standard tier. Custom domains are allowed at these levels but you don't have to change your domain if you don't want to.
Here is the overview of scaling a web app https://azure.microsoft.com/en-us/documentation/articles/web-sites-scale/
Adding a Virtual Machine (VM) is very costly as compared to adding instance. On top of it, Redundancy (recommended) for the VMs, adding NIC etc will blow up the cost. Maintenance is another challenge. PAAS (webApp etc) is always a better option than IAAS.
Serverless offerings like Azure Functions can also be thought of. They support http trigger and scale up really well.
Related
I'm interested in using Azure as a PaaS solution to host a Node Js app that I'll be developing in the few coming months. I've done a fair bit of research on the pricing models and tiers so I sort of have a grasp on that, however, I'm not sure how to accurately spec my server requirements. When looking at pure CPU, Memory and Storage specifications between the Basic, Standard and Premium plans they all look similar, with the exception of storage I suppose.
The application I intend to build will primarily perform CRUD based actions. It will not host large images/videos and static files will be used in JS libraries or small images for theming (icons, logos etc I'm hoping there's a CDN). I anticipate no more than 1000 web page requests per day and the AppService is only intended to serve as a WebApi and Web Server, I intend to host the DB on Mlab.
I'm looking for an option that will give me reasonable page load and server response times (1-2secs). The app service also needs support for SSL, is that something I need to get from Microsoft or I can purchase and apply elsewhere.
Finally, I'd love to be able to test and dev on Azure, as from my experience it is better to do so on an architecture that matches your production. Is there any low cost Dev/Test server options that I can use instead of using the production service (which I anticipate will exceed my test performance requirements and would also cost more)?
While the CPU, memory, and storage options may look similar between the plans, the VM underneath and the additional features are not.
For plans:
Shared/Free are plans where you share a VM with other users. You have
quotas for how much of the VMs resources you are allowed to use, and
if you go over them the site will be shut down until the quota
resets. This is fine for dev/test environments, but can be risky for
production as a traffic spike can cause your site to be turned off
temporarily.
Basic plans give you a dedicated VM for your app, so there are no
quotas and thus removes the risk of having your site shut off it gets
too popular.
Standard adds autoscaling (the ability to increase and decrease resources based on usage metrics) and SSL.
Premium is similar to Standard, but the underlying VM is running on better hardware.
The Shared plan and higher (basically anything but free) offers load balancing and custom domains. You can purchase a domain within your Azure account or bring your own.
The default yourwebsite.azurewebsites.net is protected by the azurewebsites.net SSL cert. However, if you use a custom domain and need SSL support, then you need to be on a Standard plan or higher. As with domains, you can purchase one through Azure or bring your own.
You can put a CDN of your own choosing in front of your Azure App Service, or you can use Azure's CDN. It is not included in the App Service plan.
For production with a custom domain and SSL, you are looking at one of the Standard plans.
For dev/test there are a couple ways you could go. If your dev server doesn't use any of the extra features like custom domains, you can scale the plan up and down as you please. That means you can scale up to the matching plan for final testing of a release, but leave it in a lower tier the majority of the time.
The second option is to use deployment slots to create your dev site on the same VM as your prod site. You need to be on a Standard plan or higher to use this feature, and it comes with some added benefits. Particularly that you can swap which code is in production or funnel some of your traffic to a staging slot before swapping new code into production.
We have a new requirement, summary follows,
Around 30 sites to be developed.
Should use Umbraco.
All the sites should need have a common Umbraco backend.
Single SQL DB.
Some of the sites will be bilingual.
Load balancing architecture required.
We did the POC for the same with 3 sites in a single instance of umbraco by adding root nodes and assigning proper host name, permissions etc and it worked fine.
But in the real case, will it work smoothly ?
We checked the following article regarding flexible load balancing in Umbraco and planned to move with Azure as it is mentioned as the first choice in the article here.
Is anyone has any similar kind of experience ?
Please share, your help would be greatly appreciated.
AFAIK, Azure Web Apps support Built-in autoscale and load balancing. I assumed that web apps leverage Application Request Routing. ARR Affinity is enabled on your Azure App Service by default. This means that if you are running multiple instance of your App Service, clients will be directed to the same instance for each request. For more details, you could refer to here.
Also, you could leverage Traffic Manager with your azure web app for load balancing, which could distribute the traffic to your web app endpoints in different datacenters (global route traffic).
Here are some tutorials, you could refer to them:
Create a Traffic Manager profile
Scale up your app by changing the pricing tier, then you could get more CPU, memory, disk space, etc. For more details, you could refer to Scale up your pricing tier.
Scale out your app to multiple instances manually or automatically based on your configured performance peaks. For more details, you could refer to Scale instance count manually or automatically.
If Azure App Service plans are virtual machines dedicated to the Web, API, Logic, and Mobile apps defined within them, does that mean that a web app in an app service plan is an instance of a virtual web server in IIS on that virtual machine?
Assuming this is the case and that each virtual web site gets it's own application pool, is there an Azure scaling strategy or scenario where more than one worker process in that app pool will run, creating a web garden? My understanding of web app scale out is that it results in additional VMs being allocated and not additional worker processes.
The scaling strategy will depend upon the pricing tier you have opted for.
Basically each Service Plan will contain a collection of Web, API, Logic, Mobile apps. These will form a web garden within the Service Plan server you choose.
If you initially choose a single B1 Basic Service Plan, you will get a single virtual machine with all of your applications running on that. As the load on that server increases, you can scale it up to larger servers, but it will still be running on a single server.
If you then choose to create a second instance (and a 3rd, 4th, 5th...) that second server will be a replica of the first server, with the load being balanced between the two. (3,4...)
While I've not seen documentation for this, I would imagine that each Web, API, etc app is run under its own application pool / worker process, and scale out is simply duplicated instances.
I'm not sure what a Virtual Server is, but each app runs in its own dedicated application pool and w3wp.exe process. There is only a single w3wp.exe process per application pool, so no web gardens.
Is there a specific reason you think you need these to scale your apps? In most cases, using web gardens is the wrong way to scale, as adding more processes can cause unnecessary overhead (amongst other problems - you can find some useful resources on the web). You almost always want to prefer threads over processes for improving concurrency. If you're running out of physical resources (CPU, memory, etc), then the correct way to scale is to add additional VMs.
I am trying to scale a web app on Azure from a single web instance to multiple instances. The web app does a fair amount of processing of per-user state, it's also fairly interactive so latency is important. We currently have a single database, testing has shown it is not the bottleneck so for this question let's assume we don't have to worry about scaling it, all instances will hit the same database. In this case, I think per-user load balancing is the best option, as per-request will result in per-user state being duplicated in lots of web instances. Apart from the issue of maintaining consistency, I am concerned this would result in unacceptable latency for end users.
This link says that ARR does per-user load balancing by default on Azure. However, the Traffic Manager, which from what I can gather is automatically enabled when you spin up multiple web instances on Azure, does per-request load balancing.
So my question is, which of these two load balancing schemes will I be using if I add a few more instances to my Web Hosting Plan? If I need to manually disable the Traffic Manager, what is the best way to do this?
Calum - you can leverage the standard SQL Session State Provider in Azure or you could look at the Azure Redis Cache provider as well for backing stores for user session state.
When deploying to Cloud Service Web Roles you automatically get a load balancer instance in front of your hosts. It's relatively transparent other than configuration of Endpoints. Each newly added/removed auto-scaled instance gets added to the Cloud Service and is automatically added/removed to the load balancer.
As others have said, Azure Traffic Manager provides a higher level service which can direct traffic to multiple Azure Regions (data centers) and even on-premises endpoints.
A good overview of Load Balancing can be found here: http://azure.microsoft.com/blog/2014/04/08/microsoft-azure-load-balancing-services/
Is it possible (and how) to load balance Azure web sites?
Situation is that I have a web site which I deployed to few redundant nodes. Now I would like to set up load balancing for reliability purposes.
I see that load balancing is done using Traffic Manager service which I tried to use, however Traffic Manager doesn't allow me to add a web site endpoint. It only allows me to add a custom virtual machine I have. On a side note, web sites are running in standard mode which means each runs on it's own VM which led me to believe I could load balance them.
I see people create separate VMs with Windows Server and use IIS ARR to perform actual web request load balancing. Is there a way in Azure to load balance web sites directly?
While converting over to web roles can very well suit your needs, an easier alternative may be to simply promote the web site up to the 'standard' tier, then increase the instance count. Windows Azure will then automatically handle load balancing the instances and even help ensure session affinity (which web roles can't do unless you jump through additional hoops).
Why not make your sites use Web Roles?
This only requires a very small change to the project to add a startup class.
These are automatically load balanced.
You are required to have at least two role instances to trigger the SLA.