web.config中的debug = true =坏事？

Posted 2021-04-11

我们看到很多虚拟内存碎片和内存不足错误，然后它达到了3GB的限制。

编译调试在web.config中设置为true但是我从每个人那里得到不同的答案，调试设置为true会导致每个aspx编译成ram的随机区域，从而破坏ram并最终导致内存不足问题吗？

答案

Scott Guthrie（ASP.NET开发团队经理）有一个interesting post about it。

你不应该离开debug="true"最重要的一点是：

1. ASP.NET页面的编译需要更长时间（因为某些批处理优化被禁用）
2. 代码执行速度较慢（因为启用了一些额外的调试路径）
3. 在运行时，应用程序中使用了更多的内存
4. 从WebResources.axd处理程序下载的脚本和图像不会被浏览器缓存，导致客户端和服务器之间的请求更多

他还提到了machine.config中的标志<deployment retail=”true”/>，它允许全局覆盖机器上运行的所有应用程序（例如生产服务器上）的debug =“true”标志。

---

更新：使用debug="true"部署Web应用程序仍然很糟糕，因为您可以在Scott Hanselman's recent blog post中阅读：

这就是为什么debug =“true”是坏的。说真的，我们不是在开玩笑。

• 覆盖请求执行超时，使其有效无限
• 禁用页面和JIT编译器优化
• 在1.1中，CLR导致过多的内存使用，用于调试信息跟踪
• 在1.1中，关闭动态页面的批量编译，导致每页1个程序集。
• 对于VB.NET代码，导致过度使用WeakReferences（用于编辑和继续支持）。

一个重要的注意事项：与有时认为的相反，在元素中设置retail =“true”并不是debug =“true”的直接解毒剂！

另一答案

除非您确实需要调试应用程序，否则应在web.config中将debug标志设置为false。

在调试模式下运行可以在某种程度上增加内存使用量，但它可能不像你所说的那样严重。但是，您应该将其设置为false以消除它所具有的效果，并查看是否可以注意到任何改进。

在调试模式下运行时，垃圾回收的工作方式不同。变量的生命周期从它的实际使用扩展到变量的范围（能够在调试器中显示值）。这使得一些对象在被垃圾收集之前活得更长。

在调试模式下编译时编译器不优化代码，并且还添加了一些额外的nop指令，以便每个代码行至少有一条指令可以放置断点。

在调试模式下抛出异常需要相当长的时间。 （但是，通常代码不应该经常抛出异常。）

另一答案

它绝对会影响内存，只需看看一些perfmon计数器并与两种配置进行比较。

如果你的网站有很多文件，我会更关心asp.net temp文件夹中的disk io。

情侣问题......

1. 你的App_Code中有很多文件吗？
2. 您是否允许该网站可更新或您是否正在发布它？
3. 如果是这样的网站经常更新或是否有部署过程？
4. 什么是硬件配置？

为什么不使用多种配置？

Web.Debug.Config - 打开调试Web.UAT.Config - 无论您的偏好是什么Web.Release.Config - 关闭调试

通过这种方式，您可以最大限度地减少回归配置错误，例如开发人员使用debug =“true”检查web.config

另一答案

AFAIK“debug = true”不会导致你提到的情况。

我在使用动态创建图像的ASP.NET应用程序时遇到了同样的问题。

所以我认为你没有处置资源有问题。

如果将带有代码隐藏文件的aspx文件部署到服务器。当请求到达aspx时，它将被编译一次。然后它将被存储到缓存中，直到文件发生变化。

另一答案

在生产系统上始终设置Debug = false。正如标志所示，在调试开发系统时，它应该只设置为true。

此标志与内存碎片问题无关。