在IIS上，ASP.NET Core应用程序启动非常缓慢

Question

我们正在通过TeamCity和Octopus部署我们的新.NET Core Web Api，它在IIS后面运行Kestrel。除了第一个请求需要大约2分钟之外，一切都正常。也就是说，在部署后的第一个请求和在IIS上重新启动站点后的第一个请求都需要这么长时间。

为了发布应用程序，我们使用：

dnvm use 1.0.0-rc1-update1 -a x64
dnu publish --configuration release --runtime active --no-source --include-symbols

在同一IIS实例上运行的旧应用程序需要约15秒钟才能响应第一个请求。我们的.NET Core应用程序使用与部署在IIS上相同的实际代码仅通过Kestrel运行，需要约15秒钟来响应。

剩下的1分45秒发生了什么 - 为什么需要这么长时间？

我们该如何进行调试？

更新：

事实证明，IIS无法正常关闭Kestrel进程（dnx.exe）。它会崩溃并显示以下错误：

Unhandled exception at 0x00000000776E298A (ntdll.dll) in w3wp.exe: 0xC000070A: Status 0x (parameters: 0xFFFFFFFFC0000008, 0x0000000000000324, 0x000000000167D930, 0x0000000000277520, 0x000007FEE60388F4).

如果我手动终止dnx.exe进程，然后重新启动站点，它会启动得非常快，因此我的理论是Octopus部署步骤某种方式遇到了相同的异常，因此IIS必须等待主进程超时，然后才能生成一个新的工作进程。

我该如何使IIS正常关闭dnx进程？ 我如何从IIS获得更易于理解的异常信息？

- severin

---

您可以使用跟踪技术（例如IIS侧的失败请求跟踪和ASP.NET侧的ETW跟踪）来检查时间的消耗情况。 - Lex Li

Answer 1

问题的原因是IIS无法优雅地停止运行Kestrel的dnx进程，必须等待超时才能启动一个正常工作的进程。

为了解决这个问题，我们在Octopus Deploy过程的第一步中添加了一个PowerShell脚本来手动停止dnx进程：

Stop-Process -processname dnx -ErrorAction SilentlyContinue -Force

为什么 IIS 无法优雅地终止工作进程以及如何修复，我仍然不清楚。

- severin