• 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的情况,你会开始在虚拟内存中搞出碎片,这将会更难的找到足够的空间来存储托管堆,很有可能会导致内存异常。

    另一种情况是,如果设置debug=false,你修改了一个aspx页面,这个页面就需要重新编译,但这不会导致应用程序域(appdomain)重新加载,这样整个程序就不会重新批量编译,单个页面会被单独编译,生成一个dll。所以不要在一个运行着的服务器上经常行的改变你的aspx页面。

    在machine.config中有一个配置选项,允许重新编译多少个页面而应用程序域不重启动。缺省的是15,所以在有15个重新编译行为之后,应用程序域会重新启动,这个跟你修改web.config 或bin目录导致应用程序域重启一样。

    代码优化

    JIT为了能够单步的调试代码,并不能够真的优化代码,所以debug模式下的代码性能就会比release模式的要差。

    如何在内存dump文件找出这些?

    要确定你的应用程序时候运行在debug模式下,在sos.dll中有一个很灵巧的命令是 !finddebugtrue,它会列出你需要的信息。

    0:016> !finddebugtrue

    Debug set to true for Runtime: 61b48dc, AppDomain: /MyDebugApplication

    Debug set to true for Runtime: 1f50e6d8, AppDomain: /MemoryIssues

    Total 16 HttpRuntime objects

    要找出你忘记编译成release模式的模块,你可以运行 !finddebugmodules

    0:016> !finddebugmodules

    Loading all modules.

    Searching for modules built in debug mode...

     

    MyDebugApplication.dll built debug

    MemoryIssues.dll built debug

    fl4sq-9i.dll built debug

    wepr1t3k.dll built debug

    r9ocxl4m.dll built debug

    zmaozzfb.dll built debug

     

    Done Seaching

    那些8个字母的dll是JIT引擎编译的aspx页面。

    噢,前面我忘记了….当你从debug=true改变到debug=false时,把 asp.net 临时目录里的程序集删除掉,这样你不会有那些导致不会批量编译的旧垃圾。

    在asp.net 2.0中,在machine.config中有一个开关量,可以吧debug=true 关闭,所有有了他,你不必担心那个应用程序是debug模式或不是。

    <configuration>

        <system.web>

              <deployment retail=”true”/>

        </system.web>

    </configuration>
  • 相关阅读:
    残疾流浪歌手的令人陶醉的声音
    关于浏览器参数的获取
    项目开发文档模板
    scoped_ptr源码
    从逗号分隔的字符串中删除某个子串的js函数
    合并两个数组的js函数
    comutil.h移值(_com_error,_bstr_t,_variant_t类的移值)
    判断两个对象是否相等的js函数
    托管可执行文件的结构(The Structure of a Managed Executable File)
    访问cookie的js函数
  • 原文地址:https://www.cnblogs.com/Leung/p/1208614.html
Copyright © 2020-2023  润新知