我遇到了WCF问题并且启动时间很慢，因此我将所有代码都切换为使用WebAPI。虽然启动时间已大规模减少（约8-15秒降至~2），但启动时仍有奇怪的延迟。目前约为2秒但随后的呼叫始终低于0.5秒，直到超时发生。
我查看了所有ApplicationPool设置，以确保没有任何启动延迟或空闲超时设置。
我发现此链接Very slow first call to web service对我没有帮助 - 我仍然在冷启动时获得相同的速度问题。还发现这个First call to web service each day is slow似乎并不适用于我。
我在我的WebAPI服务上启用了跟踪，发现我的第一次和第二次通话之间的唯一区别是显示WebHostHttpControllerTypeResolver.GetControllerTypes的两行。我似乎无法对此发现太多，但这是我能看到的唯一区别。
是否还有其他类型的日志记录可用于确定实际发生的情况？
答案 0 :(得分：2)
这是我在问题下面的对话摘要
那么超时永远不会相同，但同样的球场......扩展，我发布服务器 - 第一次呼叫是~2秒 - 后续呼叫是~0.5秒。在大概20分钟后（很难确定实际时间），同样的情况发生 - ~2然后~0.5。
20分钟 - 这是默认的 AppPool空闲超时（分钟）。所以听起来IIS卸载你的应用程序池，以便下次你在20分钟后点击它“再次加载它”（不确定它是否重新编译）因此滞后。你可以让它0来禁用超时（注意反响）或者只是让它更大。
如果您禁用超时，您可能需要考虑添加计划任务，以便在使用率较低时（可能是凌晨1:00或适合您需要的时间）回收您的应用池。
我遇到了WCF问题并且启动时间很慢
这也是我的经验（使用IIS托管的WCF），就像我上面提到的那样，只是禁用了我的WCF服务的应用程序池的超时。这使他们保持温暖和温暖。另外，当我知道我的系统不会用于允许IIS进行一些内务处理时，我每天都有回收事件。
在IIS中托管的WCF就IIS而言，只是另一个IIS应用程序。 ：）