0
votes

I have a Web Api service running in Cloud Services in Azure. I noticed like many have here that the first call to the service seems to take forever (almost 1 minute) and subsequent calls are normal. I looked around and came about a few resolutions, one being adding a startup script to the Role Startup of the Deployment

REM *** Prevent the IIS app pools from shutting down due to being idle.
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.processModel.idleTimeout:00:00:00

REM *** Prevent IIS app pool recycles from recycling on the default schedule of 1740 minutes (29 hours).
%windir%\system32\inetsrv\appcmd set config -section:applicationPools -applicationPoolDefaults.recycling.periodicRestart.time:00:00:00

As well as setting the AppPool's Start Mode Property to AlwaysOn. After making these changes, I am still seeing latency issues when the Cloud Service is initially deployed and the web service is hit. So what could be going on here? Do I need to write a script to "warm up" the web service on startup of the Cloud Service?

3

3 Answers

1
votes

I had a similar issue, Isaac, and as you suggest, added several calls to the API after a new deployment (automated) so production users would not experience the delay.

I'm also curious if there is a better way.

0
votes

You can use staging environments for zero downtime deployments. Deploy your app to staging slot and warm up there. When you feel ready, just swap. Azure will drain current connections and change the endpoints smoothly. Check this.

0
votes

I use an Azure Scheduler Job that does a GET on my url every 5 minutes. You can schedule it however often you need. It also has auto retry on by default, and you can create actions for failure as well.