当我的大型ASP.NET站点更新时，IIS必须重新编译它。有没有办法显着减少编译时间？

Question

DotNetNuke是一个大型的ASP.NET CMS，大多数都是预编译的，其中包含的大部分模块也是如此。

当我们部署DotNetNuke站点更改时，我们会在第一页点击时发生两次重新编译。

1. 在bin文件夹中替换DLL时发生的应用程序级重新编译
2. 每次首次访问单个模块时，都会在该特定模块上进行一些重新编译。

有没有办法分配更多的CPU容量来编译IIS 7中的asp.net站点？

• 我想使用多个核心，或至少做一些事情来减少重新编译时间。

问＆安培; A

您应该使用预编译的ASP.NET。为什么不是你？

• 我们正在使用预编译的ASP.NET。仅仅因为ASP.NET应用程序被编译成DLL并不意味着ASP.NET运行时不会进行额外的重新编译以便将其提供给访问者。

你怎么知道它重新编译而不是填充缓存或什么？

• 在上述页面命中期间，查看服务器上的任务管理器显示编译器可执行文件的50％CPU使用率。为什么50％？ 2核服务器。

Answer 1

设置<compilation optimizeCompilations="true" />

  

指定如果更改顶级文件，动态编译是否将重新编译整个站点。顶级文件包括Global.asax文件以及Bin和App_Code文件夹中的所有文件。如果为True，则仅重新编译已更改的文件。

来源：compilation Element (ASP.NET Settings Schema)

有关优缺点的更多信息，请参阅优化动态编译下的Understanding ASP.NET Dynamic Compilation。导致错误的主要原因是删除或更改现有方法签名，导致已编译的页面在重新编译之前抛出MissingMethodException。

您还可以考虑减少批量编译的批量大小，或者完全禁用它。我相信这会减少单个页面的编译时间，但会生成更多的程序集并消耗更多的内存。

Answer 2

我过去曾与DotNetNuke有过完全相同的经历。我们的问题是我们安装了大约125-150个模块，所有模块都有自己的组件。它们的绝对数量将导致第一次请求延迟接近一分钟或更长时间。在部署期间更糟糕，因为我们会有目的地重新安装我们自己的自定义模块。后来，我们调整了部署脚本以避免安装已安装的模块，这有帮助。但是，第一个请求仍然是一个熊，因为它运行的是VB.NET和C＃编译器（我们的模块是C＃，而DNN当时是VB.NET）。

虽然我们使用optimizeCompiliations属性来帮助您，但您还需要考虑确保没有实时病毒扫描程序监视代码所在的目录和Temporary ASP.NET Files文件夹。这会使编译速度变慢。

接下来，您可以考虑使用ILMerge将一些程序集合并到一个程序集中，但我知道我们避免使用此选项，因为它会导致我们比预期解决更多的部署问题。

最后，这是一个场景，其中一些额外的硬件并不是一个坏主意。最有帮助的是更快的CPU，只需将编译时间缩短到合理的时间。

DotNetNuke.com在他们的Wiki中有a few个性能调整提示。对性能提供最大帮助的是截断EventLog和SiteLog表，因为如果你不注意它们它们会变得非常大。在网站索引中还有一两个表，在某些版本中，它们已经失去控制。老实说，这不是你的问题。您遇到了典型的ASP.NET冷启动问题。

您可能还需要查看一些common ASP.NET performance issues。这个讲述了冷启动和热启动性能增强。

Answer 3

预编译而不是动态编译选项吗？

Answer 4

我很确定这是不可能的，因为编译是在单个线程中执行的，它不能跨越处理器。运行站点跨越处理器/核心，但第一次命中编译不会。

您可以看到的是将您的解决方案分解为项目。然后，您网站的一小部分需要完全重新编译。

Answer 5

2核CPU系统上50％的CPU利用率表明ASP.NET编译器是单线程的。您会看到四核系统的CPU利用率为25％ 据我所知，没有任何神奇的方法可以将其转换为多线程编译器。

然而，您可以做的一件事是在部署之前使用ASP.NET compilation tool预编译整个站点。在dev / staging框上执行此操作并部署到prod，并且您的prod部署不应该受到这些延迟的影响。

必须咬我的舌头，但我不得不问;你真的部署到经常这是一个问题吗？