ASP.NET Memory：如果你的应用已经在生产环境中，那为什么还要debug=true

最新推荐文章于 2022-05-01 22:35:53 发布

danny0609233

最新推荐文章于 2022-05-01 22:35:53 发布

阅读量910

点赞数 1

文章标签： asp.net dll compilation deployment 优化服务器

ASP.NET Memory：如果你的应用已经在生产环境中，那为什么还要debug=true

问题陈述：

确保在每个asp.net 应用中web.config里面在<compilation>节中的“debug=false”。这个在开发中的缺省设置是true，而且他是我们经常的犯的错误，把这个缺省设置部署到在生产环境中的实际应用。你没有必要设置为true，因为它会导致内存的总开销和低效率。

保留debug=true会导致什么问题？

当设置为true或者false，主要有3个主要的差别

1) asp.net 过期时间

2) 批量编译

3) 代码优化

asp.net 过期时间

当设置为debug=true时，asp.net 请求不会过期，这个会允许你用vs studio来按照你自己的步调来调式程序而不用担心这个请求会突然消失。当然，在生产环境中，超时过期是确保请求不会被卡住，这就是针对第一个的理由。

批量编译

简单来说，当设置为true，我们不会进行批量编译，而false 则会。

这是什么意思？

当一个 aspx、asax、ascx页面第一次被请求，它会被编译成一个dll程序集。这个程序集有一个类似3ks0rnwz.dll的名字（8个字符），里面保存的是实际的ascx、asax或aspx的类（不是code behind 的代码），这个文件在C:/WINDOWS/Microsoft.NET/Framework/版本/Temporary ASP.NET Files文件夹的应用程序名下面。

那些code behind的类被编译到程序集的主dll中，他和其他的dll一起放在应用程序的bin目录下，拷贝映射到asp.net 临时目录。

回到3ks0rnwz.dll… 如果我们把debug设置为true，那么会为每个aspx、asax或ascx页面创建一个dll，而且是debug模式的dll，所以如果你有100个页面，那会创建100个程序集，他们会在页面被请求的时候创建。

如果我们把debug设置为false，那会批量编译。意思是第一次请求任何页面的时候，会编译整个应用程序，生成一个很大的dll，这是一个事实，但有些修正，用户控件（ascx页面）会被编译成到一个分开的程序集中，和aspx页面分离，而aspx页面会分组按他们所引用的用户控件分组编译，global.asax也是分开编译。编译也是基于目录的，即如果应用中还有子目录，那子目录也是单独编译，避免同名冲突，因为在可能有相同名字的aspx页面在不同的目录中。但总的来说，相比100个dll，你肯那个只有4 或5个dll。

因为代码都是相同的，所以合在一起的dll合单独的dll的大小并没有很大的差别，但那有一个很大的…总体消耗，对每个dll而言。在dubug模式下编译的dll有一个为了调试而需要的资源消耗。最重要的是，这些dll不会在内存中一个挨着一个排列着，所以，针对有很多的dll的情况，你会开始在虚拟内存中搞出碎片，这将会更难的找到足够的空间来存储托管堆，很有可能会导致内存异常。