This problem has dogged my life for the past year, on and off, but I think I've finally got it licked. Hat tip to all the internet resources I've trawled though, pillaged and mashed up over the course of that time.
Good old Azure web apps spin down after 20 mins of inactivity, and as far as I can tell there's no way of hacking at Azure's application pool settings like you could if you were running your own IIS.
Why is this necessary? There's a slow spin-up time, granted, but once the site gets going, everything's fine, right? Well, not quite. If you're a new startup, you're desperate for new traffic. When someone DOES visit, they're rewarded with ridiculously long wait times. This is useless for getting traction.
Three things cause this slowness:
- Site startup (probably app pool startup, this isn't really my forte)
- Page/view compilation
- EntityFramework query startup.
What can we do to tackle this? Some are more useful than others, and some are no better than a chocolate teapot.
- Always On setting - not reliable (site spins down.) Chocolate teapot category. Only useful for WebJobs marked 'Continuous'.
- A custom WebJob to do a keepalive - pings website - also detected by Azure or not?
- Two useful areas - page precompilation, and EF query precompilation.
- VS has 'precompile before publishing', but unsure how useful this is too.
- Precompile manually on site in Application_OnStart. Add a little bit of code to recurse through your Views.
- Use the NuGet EFInteractiveViews package to precompile the queries, and add a small bit of code too to initiate this.
I'll write this up in a more detailed fashion soon.