6

在将我们的 ASP.NET（主要是带有 AJAX 的表单）应用程序部署到一台特定的生产机器之后，重新编译过程（其中 w3wp.exe 为每个 aspx 或 ascx 文件调用 CSC.exe）会持续数小时。因此，Web 应用程序的性能非常缓慢。当部署到其他生产机器时，这些完全相同的应用程序会在几分钟内完成编译。

这些 aspx 编译只在 ProcExp 中可见一秒钟，它们使用的命令行涉及一个在编译后立即删除的参数文件，因此我很难监控正在编译哪些文件，或者查看是否是同一个文件正在编译不止一次。有什么方法可以记录编译过程，以便我可以尝试找出这台机器行为异常的原因？

我知道我们可以使用 aspnet_compiler.exe 来预编译整个应用程序，但是将其纳入构建和部署工作流程（TFS 2010 加上 OctopusDeploy）会有点痛苦。此外，我在命令行“手动”进行预编译的尝试不起作用。预编译成功，但是当 IIS 指向目标目录时，对任何文件的任何请求都会引发此类错误：

异常类型：HttpException

异常消息：文件“/default.aspx”尚未预编译，无法请求。

ETA：这就是我想从这个问题中得到的

  1. 我应该检查什么来确定为什么这台机器要花这么多时间编译？
  2. 我可以做些什么来记录正在编译的文件是什么时候？
4

3 回答 3

0

我们使用预编译作为解决此问题的唯一方法，否则您将看到多个msbuild.exe进程。动态编译不能给你想要的结果。使用Visual Studio 2012或稍后创建发布配置文件然后将该配置文件提交到源代码管理非常容易，这样您就不必一次又一次地这样做。此外，您将应用程序性能不佳归咎于构建过程，我建议您研究一下如何优化您的应用程序本身。就像我们一样，我们的表现也很缓慢，然后我们改用SessionPageStatePersister它改善了很多性能问题。我会推荐以下很棒的视频，只需浏​​览它们并检查您已经完成了多少以及您可以做多少。

性能优化您的 ASP.NET Web 应用程序

深入探讨：提高 ASP.NET 应用程序的性能

于 2016-01-12T14:23:08.817 回答
0
  • 清理 Microsoft.Net 框架中的临时目录
  • 在磁盘上运行 chkdsk
  • 临时禁用防病毒/反间谍软件
  • 如果有人（其他 csc.exe 和 w3wp.exe）访问临时 dotnet 目录，请使用 sysinternal filemon 工具检查
于 2016-01-13T13:51:00.237 回答
0

动态编译

ASP.NET动态编译应在编译后将文件保存在缓存中，并仅在发生更改时重新编译。正如MSDN所说：

对动态编译文件的任何更改都会自动使文件的缓存编译程序集失效，并触发所有受影响资源的重新编译

在您的情况下，动态编译最有可能以触发重新编译的方式影响自身- 在循环中。

你检查过动态编译的优化吗？

如果您希望能够在不重新编译整个站点的情况下更改顶级文件，可以将Web.config文件中编译元素的optimizeCompilations 属性设置为true。

注意：对于 .NET Framework 3.5 中的用户，他们需要一个修补程序才能使用该参数。

日志记录

您是否已经将日志解决方案插入 asp.net 框架？

能够调查问题的最低要求是ConsoleLogger（从 Web 浏览器可见）或Logger 将日志事件写入文件。
然后，您必须将 LogLevel 配置到最低限度：Debug或Verbose应该可以解决问题。

还有一些第三方日志框架可以插入 System.Diagnostics 以提供更多功能。

一般建议

如果您有错误问题，例如循环重新编译，您应该尝试在开发人员机器上重现它。逐步调试重新编译过程会更容易。这篇关于重新编译期间发生的事情的文章可以帮助您。在整个部署和编译过程中，这更加完整，但它是针对 ASP.NET 2.0

如果您有性能问题，您应该在开发人员机器上分析您的网站，找出真正的性能问题所在并修复它们。

于 2016-01-13T07:26:08.737 回答