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

Question

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

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

Answer 1

Scott Guthrie(ASP.NET开发团队经理)有一篇有趣的帖子.

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

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

他还提到了debug="true"machine.config 中的flag >,它允许全局覆盖在机器上运行的所有应用程序的debug ="true"标志(例如在生产服务器上).

更新:部署Web应用程序<deployment retail=”true”/仍然很糟糕,您可以阅读Scott Hanselman最近的博客文章:

这就是为什么debug ="true"是坏的.说真的,我们不是在开玩笑.

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

一个重要的注意事项:与有时认为的相反,在元素中设置retail ="true"并不是调试="true"的直接解毒剂!

Answer 2

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

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

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

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

在调试模式下抛出异常需要相当长的时间.(但是,通常代码不应该经常抛出异常.)

Answer 3

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

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

所以我认为你有一个未处置资源的问题。

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