Support warm up/initialization in Azure Websites
My ASP.NET application's Application_Start takes ~10 seconds. Currently the first request to my site after an app pool restart (or a new deploy) suffers from really slow performance. I would like the ability to not get traffic on a new deployment until it has been fully initialized.
Hello, Jeff. I’m glad to report that this is now available. Please visit the following post to learn more about it: 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
David Twamley commented
For any that voted on this idea, consider validating/voting for the other half of this idea (warming up individual pages at app start):
If there is a good workaround or smarter way to do that please share your knowledge on these SO questions.
BTW, I really do think that deployment swap is fantastic. Thanks Microsoft :)
Bart Sipes commented
Does the "Always On" support just announced resolve this?
You can use Job scheduling (Free) in Windows Azure :
Jeff Moser commented
1. I have a live site in production. When I do a git deploy of the updated site. I want it to compile the code and warm it up (via App_Start) before it swaps into production. Thus, existing users see no painful waits (now on the order of ~30 seconds). It's OK for staging to have the cold start problem. One extra clarification is that it'd be super helpful if during the transition the requests in-flight (i.e. large file uploads) didn't get cut over (i.e. aborted) but rather continued on the old code/AppPool until they finished. This would greatly help in making sure there are no adverse affects of a new deploy.
2. We are already using the Standard Tier with IP based SSL. Even with the standard tier, we can't do a deploy w/o the warmup wait currently.
There are two scenarios:
1. When redeploying, the ask is to warm up the site?. The only valid option is have a warm the stage site and then 'swap' between the stage and production site. End users using the site will no notice the cold start, but you (the developer) will on the stage site.
2. Quick clarification - you are asking to have your site in memory all the time and ready to response to incoming HTTP request in a split second. Did you consider Standard tier? This option doesn't contradicts the need to have a warm site swap (scenario #1)
Jed Grant commented
I can't agree with this enough, as a newer developer trying to get his feet wet and choosing azure, the incredibly SLOW performance of the site after the application pool restarts is an ABSOLUTELY AWFUL experience for end users. This is quite nearly a deal breaker because people get impatient and quit the site, especially when they are new and user acquisition is critical to your business.