asp.net - 为什么 ASP 如此频繁地编译我的 View ？

Question

我们有 4 台服务器负载均衡:

4 核 @ 2.6Ghz (E5-2650 v2)

14GB 内存

window 2012 R2

高性能电源设置

IIS 8.5

ASP 5.3

英孚 6.1

它们每个都有一个应用程序池，其中包含一个工作进程和一个网站。每个服务器都有自己的站点副本(DLL 和 View )，在本地磁盘上运行。我们使用 IIS 虚拟目录指向集群文件服务器上的共享日志文件和公共(public)图像等(仅限内容)。应用程序池设置为在空闲时不关闭(间隔为 0)，我们也禁用了每 1740 分钟的回收间隔。

我们在所有服务器上都安装了 New Relic 的 .NET 代理，查看我们缓慢的事务日志，我可以看到许多请求需要 15 秒左右才能完成。查看跟踪，我可以看到对 System.Web.Compilation.AssemblyBuilder.Compile() 的常见调用。和 System.Web.Compilation.BuildManager.CompileWebFile() .

据我所知或理解，ASP 会在第一次请求时编译这些 View ，并将其缓存(到 C:\Windows\Microsoft.Net 中的临时 ASP 文件中)，然后从那里加载以供后续请求。

我很困惑这是怎么经常发生的——当我访问这些 URL 时，TTFB 大约是 400 毫秒，并且由于持续的负载，我看不到网站“丢失”了它们的缓存并需要再次编译 View 。这些页面经常被点击——它是一个电子商务商店，我可以看到它经常发生，并且在我们最受欢迎的页面上:目录(类别/品牌/性别等)列表和产品详细信息。

我已经针对每个应用程序池设置了设置以在回收时记录一个事件，并且当我在事件查看器中检查 WAS 服务时没有记录任何事件。我们还安装了 New Relic 服务器，查看过去 6 小时的数据，我看不到任何服务器上的 RAM 使用量有任何下降——这表明应用程序池正在回收。这真的让我很困惑!

我正在考虑将我们的观点作为我们发布过程的一部分进行预编译——这真的很有意义。但感觉这正在解决，或者掩盖了一个据我所知不应该发生的问题。我们以 Release模式构建我们的网站，并拥有 <compilation debug="false" />全部 web.config文件。

任何人都可以想到任何原因吗？

Answer 1

这是因为 JIT(即时)编译的工作方式。

构建应用程序时，它会转换为 .NET Microsoft 中间语言 (MSIL) 或中间语言 (IL)。

当您的应用程序被访问时，公共(public)语言运行时 (CLR) 仅将代码的已执行 IL 部分转换为 native 指令。

即时编译过程将 IL 转换为本地机器指令，它是 CLR 的一部分。

简而言之，当您运行 .NET 应用程序并且您的程序调用方法时。 JIT Compiler 从元数据中读取 IL 并将其编译为 native 指令并运行它。接下来，当您的程序调用相同的方法时，CLR 会直接执行 native CPU 指令。这个过程为第一个方法调用增加了一些开销。您可以选择使用 NGEN 预编译应用程序的其他选项，通常不建议这样做，因为您会失去一些只有 JIT 才能执行的优化，因为它了解底层硬件平台。这两篇文章有更多细节
http://geekswithblogs.net/ilich/archive/2013/07/09/.net-compilation-part-1.-just-in-time-compiler.aspx和 https://msdn.microsoft.com/en-us/library/ms366723.aspx

您还可以尝试其他一些方法来帮助您加快申请速度。您可以使用 IIS 应用程序预热模块 How to warm up an ASP.NET MVC application on IIS 7.5? ，实现分布式缓存等以缓解您的一些应用程序瓶颈。