What is happening behind the scenes when an App Service is restarted?
I'm trying to troubleshoot a slow restart for my app (ASP.Net and Sql published from Visual Studio) and I feel like understanding this would help me know what the issue is. My app starts within a few seconds on my dev machine but takes 90 seconds on Azure.
From my research, it sounds like a new service instance is provisioned, application files are copied from the shared storage to the instance and it is started. Is this correct? Is there a way to monitor the startup process to see what is slow?
Edit:
It's a tier S1 service plan. The app isn't slow, just the restart. I was hoping to understand the process so that I could understand whether the slow startup is due to my code or just the nature of the way the restart works. I've noticed that my app runs for about 10 seconds after the restart (refreshing the page), then I get a service unavailable for about 20 seconds, then the page is loading until for about 60 seconds.
It all depends which app service plan you are using, different plans have a different memory, network bandwidth, IO etc, App Service runs customer apps in a multi-tenant hosting environment. Apps deployed in the Free and Shared tiers run in worker processes on shared virtual machines, while apps deployed in the Standard and Premium tiers run on the virtual machine(s) dedicated specifically for the apps associated with a single customer.
Refer to this link for a guide on Troubleshooting slow WebApp in Azure.
Related
I would like to run Virtual Machines as Worker Role inside an Azure App Service Environment. I think I've tried and read everything. Is this scenario supported at all?
The short answer is no. Azure VM's, worker roles (cloud services), and App Services are three different hosting offerings.
Virtual Machines are an Infrastructure as a Service (IaaS) solution. Think of it as your own server in the cloud. It is the most most flexible option. However, you are responsible for managing and patching it.
Cloud Services are a Platform as as Service (PaaS). Your concerns are limited to building and deploying your application. Microsoft manages updating the underlying VM.
App Services are a higher level of PaaS. Specifically, you can think of Web Apps (formerly Web Sites) as a hosted IIS. You have the least amount of control compared to the other platform offerings, but it is the easiest way to get started.
I would suggest trying to run your application first in an App Service, then moving to a cloud service if you need more control, and finally to a VM when even more flexibility is required.
More information:
http://robertgreiner.com/2014/03/windows-azure-iaas-paas-saas-overview
http://blogs.msdn.com/b/hanuk/archive/2013/12/03/which-windows-azure-cloud-architecture-paas-or-iaas.aspx
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.
What is the correct way to way to warm up Cloud Service instances before performing a VIP Swap?
We're running two Web Role instances in our cloud service, and have already performed the following optimizations:
IIS 8.0 Application Initialization module in a Windows Azure Web Role
Controlling Application Pool Idle Timeouts in Windows Azure
Set AutoStart = true
Despite all these changes our site still takes around 10-20 seconds to start up after having performed a VIP Swap.
Is doing something like using a WebRole to hit the endpoints still the best way to go?
We are running several azure websites (or web apps) on a medium instance. I would like to know if there will be an impact on performance on any of the other sites when running a simple load test on one of them. In other words, do these sites share the same processor/memory or is this handled differently in azure?
If the apps are in the same app service plan then yes there will be an impact. Apps within the same app service plan share resources and capacity.
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
I have a NodeJS server running on an Azure free website. The server has a websocket module installed. Each connected user will cache some data with an object so that anyone else who connects can retrieve cached data from this object. The problem I am experiencing is that the server doesn't seem to keep this object around for very long. I can access the data with in for some time, but if I try later in the day, it's just gone.
Is Azure shutting down the server because it is experiencing no activity, causing the object to be deallocated? Does NodeJS deallocate objects if they aren't used after some time?
Azure Websites, as Ben pointed out in his answer, will evict idle websites. This is especially true with free/shared tiers, since your website is sharing resources with several other tenants on the same VM instances. But even with basic and standard tiers, there may be a need to evict your website (especially since you can have many of your own websites running within a single hosting plan).
With basic/standard tier websites, you have the ability to enable Always On. You'll see this option under the Configure tab:
Once you enable this, your website should remain loaded.
Yep. If there aren't any requests to the app pool, Azure Websites stops your application. That means anything in memory is lost. You can set up a cron job or scheduled task to ping your web app to avoid the app pool timing out due to inactivity.
EDIT: Or, as David Makogon pointed out,
With basic/standard tier websites, you have the ability to enable Always On. You'll see this option under the Configure tab: