Application Initialization to warm up specific pages when app pool starts
I want to use IIS8's Application Initialization feature, but it has to be enabled in the Azure Websites VM first. I need this so I can warm up a list of individual pages before Azure declares the site fit for duty and directs traffic to it. The appropriate tool for this job is Application Initialization:
There are no good workarounds I'm aware of. I don't want to leav PaaS for Web Roles just for this. I've heard others suggest traffic monitoring or custom scripts, but none of those even have access to the target instance at that crucial moment--the minute before being added to load balancing or being swapped in as the active w3wp process. By the time my custom script hit a page, an unlucky customer would have already endured the cold start.
This idea received 98 votes and was marked Completed but it really only achieved half of what was asked for:
What was deliverd--warming up a stage site and having an instantaneous swap--is truly magnificent! It makes the deployment story excellent. BUT, there are plenty of reasons why I'd have apppool starts in production outside of my deployment process. In particular:
- Every time autoscale boots up another instance to add to the web farm
- Every time Microsoft rolls us onto a new instance for security updates or resource management
Using autoscale as it was intended with fluctuating traffic means several apppool starts every day! I want to warm these instances up just as thoroughly as I would my stage site during a deployment process. Hitting the home page isn't enough for my CMS powered site either. I've got a list of 30 maybe even 100 pages that I want to warm up before that app pool is considered ready for action in the web farm. Enough people had this same problem and that is why IIS8 has the Application Initialization feature baked in now.
Now we want it enabled and baked into the Azure Websites VM image too. We can configure it directly through web.config after that.
This needs to play well with the custom domains we've configured of course. Rules like these should work fine (meaning my.domain1.com is going to resolve to this exact IIS instance not reach out to the network and hit the load balancer):
<add initializationPage="/my-slow-the-first-time-page" hostName="my.domain1.com"/>
<add initializationPage="/another-slow-page-on-a-diff-domain" hostName="my.domain2.com"/>
And yes, improving page cold start times is a worthy goal and will be pursued too.
The Application Initialization (http://www.iis.net/downloads/microsoft/application-initialization) module has been implemented and is available to use for swap (http://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/).
It has also been implemented for all other operations in which a new worker is provisioned (such as auto scale, manual scale or Azure fabric maintenance).
Deployment is now complete.
Nir and the Web Apps team.