Will "Always On" setting prevent BOTH idleTimeout and periodicRestart?

Question

Has you may know, Web sites hosted under Microsoft Azure Web Sites service are by default configure to timeout after idling 20 minutes (idleTimeout) and the application pool to restart every 29 hours (periodicRestart). This cause the web site to be slow for the first user accessing it.

I would like to know if the new "Always On" setting available on standard mode will prevent both situation from happening.

I found a few articles mentioning the feature, they are all very clear that the idle timeout will be avoided but none of them explicitly talks about the periodic restart:

One of the other useful Web Site features that we are introducing today is a feature we call “Always On”. When Always On is enabled on a site, Windows Azure will automatically ping your Web Site regularly to ensure that the Web Site is always active and in a warm/running state. This is useful to ensure that a site is always responsive (and that the app domain or worker process has not paged out due to lack of external HTTP requests).

http://weblogs.asp.net/scottgu/archive/2014/01/16/windows-azure-staging-publishing-support-for-web-sites-monitoring-improvements-hyper-v-recovery-manager-ga-and-pci-compliance.aspx

Also the Azure Documentation is not very explicit:

Always On - By default, web sites are unloaded if they have been idle for some period of time. This lets the system conserve resources. You can enable the Always On setting for a site in Standard mode if the site needs to be loaded all the time. Because continuous web jobs may not run reliably if Always On is disabled, you should enable Always On when you have continuous web jobs running on the site.

http://www.windowsazure.com/en-us/documentation/articles/web-sites-configure/

Overnight

Hi! Could you say about your experience in Azure Web Site and "Always on" setting. Can I be sure, that site won't restart and shutdown by idle and periodic timeout? I create new question on SO for this: #25546177 – Crinose

Answer 1

Yes both of them will be prevented.

The default 29 hours periodicRestart was never on Azure Websites. That feature is an IIS feature that was enforced by WAS and was designed to run on a server level meaning restart all the worker processes on an IIS server. Both these things (WAS and IIS Server) don't apply to Azure Websites as WAS was the process management component of IIS and that was very specific to one box setup. Azure Websites uses a different process management component that doesn't have periodicRestart.

Aircraftman

Following your answer, we decided to activate the feature and monitor closely the website for the next 48 hours in order to verify no undesire periodicRestart is performed. I will let you know of the results. Thank you! – Overnight

Another useful feature that you may consider combining with Always On is AppInit. If a site happens to restart for any other reason(site crashes, unhealthy VM, VM windows updates, Azure Websites Upgrade, etc) Always On will make sure to start your site and send a request to the site root /. If that is all your site requires to warm up, then you are done. If not, you can list different URLs in web.config using appinit, and once the site root is hit, the worker process will take care of hitting all those URLs. note that app init doesn't support authentication. – Aircraftman

What about during deployments? If you have Always on set, and you deploy to your website, will there still be down time? Is that why we need to use SLOTS for warm up? – Mingmingche

well, during deployment your app has to unloaded and reloaded in memory. The old bits get swapped by the new bits. Some complex applications can require > 2 or 3 minutes to get back online once restarted. These 2 or 3 minutes constitute a down time for the app, as the app can't really serve any requests while it's being initialized in memory. This is what deployment slots help with. You deploy in a different process in memory (a different slot), warm up, then have the load balancer redirect traffic to the new ready process (the swap). – Aircraftman

Does that mean Azure Websites don't utilize IIS underneath? Or, IIS somehow configured to work without WAS component? – Stevana

The latter. IIS has multiple components. There is the runtime itself that runs in the w3wp.exe process, that is shared between azure and IIS, then there is the management portion of IIS which WAS is part of, that is not used on Azure. – Aircraftman