windows azure website load time

There is now a new feature available for Windows Azure Websites in 'Reserved' mode that will keep your website warm. You can now turn on "Always-on" under the "Configuration"-tab on your Azure Website. As explained in this blog post:

When the new “Always On” feature is is enabled on a site, “Windows Azure will automatically ping your website regularly to ensure that the website is always active and in a warm/running state,” Guthrie writes. “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).”

Easiest way to keep a website warm is to call it regularly using the Scheduler feature in Windows Azure Mobile Services.

You simply write a script in the Scheduler that pings your website every x minutes.

Here's a post covering how to do that: http://fabriccontroller.net/blog/posts/job-scheduling-in-windows-azure/

The Windows Azure Web Sites are still in preview, so there is currently no SLA with that service.

The Web Sites do idle out when in free or in Shared mode, which is likely what you are seeing. When the site idles out it actually is removed from memory, and indeed the IIS process host running the site is shut down. This is how they can get the density of hosting 100 sites on the same VM.

You can find a lot of info on the Channel9 site about why this is the case, or, as a shameless plug, here is an article that talks about how the process is handled.

Now, you mentioned that you were using a keepalivecontroller, but what exactly do you mean by that? I use pingdom.com to contantly request data for one of my websites, and that seems to do pretty well. It is still possible that a request doesn't come in and the idle time is met which then cycles the site. It is also possible that even if you always have the site running that the VM the site sites on needs to have the underlying OS updated, in which case Azure would then move the site process to another VM, which could also cause the slow start up on the next request.

I'd start logging your application start ups and then look through your logs to see how often that is happening.