问题描述
我在Azure的Cloud Services中运行了一个Web Api服务.我注意到这里有很多人，第一次致电该服务似乎要花费很长时间(将近1分钟)，随后的通话是正常的.我环顾四周，提出了一些解决方案，其中一项是在部署的角色启动中添加启动脚本
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
以及将AppPool的启动模式"属性设置为AlwaysOn.进行了这些更改之后，当最初部署Cloud Service并单击Web服务时，我仍然看到延迟问题.那么这可能是怎么回事?我需要编写脚本来在启动Cloud Service时预热" Web服务吗?
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，并且如您所建议，在新的部署(自动)之后向API添加了多个调用，因此生产用户将不会遇到延迟.
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.
这篇关于云服务始终开启不起作用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！