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

时间:2009-03-07 09:15:25

标签: asp.net web-config

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

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

5 个答案:

答案 0 :(得分:76)

Scott Guthrie(ASP.NET开发团队经理)有interesting post about it

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

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

他还提到了旗帜<deployment retail=”true”/&gt;在machine.config中,它允许全局覆盖计算机上运行的所有应用程序的debug =“true”标志(例如,在生产服务器上)。


更新:使用debug="true"部署网络应用仍然很糟糕,因为您可以在Scott Hanselman's recent blog post中阅读:

  

这就是为什么debug =“true”很糟糕的原因。说真的,我们不是在开玩笑。

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

一个重要的注意事项:与有时相信的相反,设定   retail =“true”中的元素不是直接的解毒剂   有debug =“true”!

答案 1 :(得分:12)

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

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

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

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

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

答案 2 :(得分:4)

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

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

夫妻问题......

  1. 您的App_Code中有很多文件吗?
  2. 您是允许网站更新还是发布?
  3. 如果网站经常更新或是否有部署过程?
  4. 什么是硬件配置?
  5. 为什么不使用多种配置?

    Web.Debug.Config - 已打开调试功能 Web.UAT.Config - 无论您的偏好如何 Web.Release.Config - 关闭调试

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

答案 3 :(得分:3)

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

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

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

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

答案 4 :(得分:0)

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

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