CODEWITHSUNDEEP
asp.netiisazureweb
Varun K
Varun K

Reputation: 3638

lifecycle of an azure website

I want to know lifecycle of Azure Websites – specifically:
1. Does Azure website automatically start (global.asax application_start fire) immediately after it is deployed? Or does it require external stimuli – http request?
2. How and when does it get recycled?
3. after it is recycle, does it start automatically (global application_start fire) or require external stimuli.

Actually I need to have a small background job (it also interfaces with certain incoming http requests) which I plan to invoke on startup. I know it can be done in worker/web roles, but I like instant deployment of Azure websites.

PS. I plan to use a Reserved instance for azure websites.

Thanks

Upvotes: 2

Views: 934

Answers (2)

NazimL - MSFT
NazimL - MSFT

Reputation: 201

Actually on #1 the site can automatically start if you set the AlwaysOn setting, which essentially simulates HTTP traffic to your application to keep it worker process up and running and your application warmed up. You can read more about that setting on the doc page.

Upvotes: 0

MikeWo
MikeWo

Reputation: 10985

No, Windows Azure Web Sites do not start up the web site automatically after it is deployed. Most of all because from time the site is actually created till you put content into it can very quite a bit. I verified this by creating an Azure Web Site and deploying a MVC 4 app to it. The app had a global variable set with the current date time in the Global application start, and then on the default controller it output that date time and the current date time on the server. I waited a few minutes after I deployed the code and then called up the page. The two times were almost identical which means the application start fired just prior to the controller. If something had spun up the application when I deployed, these times would be off by the amount of time I waited.

Since it doesn't spin up immediately after a deploy you'd need some outside stimulus to do so.

The site can be shut down due to being idle anywhere from 5 minutes up to 20 minutes depending on how busy the server is, even on a reserved instance I believe. If this occurs the next request in will spin it back up by creating a new IIS process on the server. When this happens it does not spin the site back up immediately, but waits for a request to come in. You can, of course, use a service like pingdom or even Windows Azure Mobile Services Scheduler to consistently send in a request to your site to keep it live.

You mention a background job and I'd wonder if you can actually do that easily with a web site. If you spin this up using new process I'm not sure that would work, and if you did this with a new thread inside the same process then you still have the same issue that the site could spin down taking this job with it.

I'm not sure what your goal is when talking about the background job interfacing with certain incoming requests so I can't say much to that. If the background job was something that will be running on a timer then you might be able to use something like the Mobile Services scheduler to send in requests on a schedule for your code to react to instead.

Upvotes: 2

Related Questions