0

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?

Isaac Levin
  • 2,809
  • 9
  • 49
  • 88

3 Answers3

1

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.

DanielG
  • 1,669
  • 1
  • 12
  • 26
  • How did you do this? Azure Jobs? a ping command running at startup? I am curious what is the best way to do this. – Isaac Levin Dec 21 '15 at 22:08
  • In our scenario, our DevOps process (which automated the deployment and build) allowed us to run an application at the successful end of a deployment (Visual Studio Release Management) as a defined step. We simply built an app that ran an AJAX call on load. – DanielG Dec 21 '15 at 22:11
  • Fair enough, I can look into something similar. Thanks for the tip. I am going to not mark your answer as the resolution as I am interested in seeing other peoples' responses. – Isaac Levin Dec 21 '15 at 22:24
0

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.

Kerem Demirer
  • 1,186
  • 2
  • 13
  • 24
  • But you still have to warm up the app correct? So the exercise is the same except you mitigate the delay on the Production Slot. Am I following? – Isaac Levin Dec 23 '15 at 14:28
  • The app pool will recycle whenever you deploy new code, you cannot prevent this. The new application will take some time to boot whether you deployed at production or staging slot. – Kerem Demirer Dec 23 '15 at 23:00
0

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.

David Frodin
  • 100
  • 5