ASP.NET配置文件machine.config与性能
与传统的ASP不同的是,ASP.NET不是运行在IIS的地址空间,而是有自己的进程。该进程可以通过XML配置文件machine.config进行配置。
ASP.NET进程: aspnet_wp.exe
传统的ASP程序的内存问题或配置不当总是会导致Internet Information Server (IIS)要么停止响应,要么崩溃。其根本原因是由于ASP进程是在IIS的进程空间中运行的。为此,ASP.NET有了自己的进程:aspnet_wp.exe。这个进程是通过machine.config来配置的。并且这个文件的设置会在整个服务器中起作用,是全局的。在这个配置文件中,可以指示ASP.NET在响应了一段时间、请求或内存使用率到一定程度后重新该进程。也可以指示ASP.NET根据主板的CPU数来创建多个进程实例。这个进程是独立于IIS的。它仅仅是通过IIS来接收和发送消息。实际上,在服务器启动后,只有当用户开始使用ASP页面时,这个进程才会创建出来。如下图所示:
配置文件:machine.config
在安装时如果没有改变安装路径,machine.config会被安装在C:\WINNT\Microsoft.NET\Framework\v1.0.3705\CONFIG\machine.config。与进程相关的配置是在文件的“processModel ”中。下面是缺省的设置:
1 | <?xml version="1.0" encoding="UTF-8"?> |
2 | <configuration> |
3 | <system.web> |
4 | <processModel |
5 | enable="true" |
6 | timeout="Infinite" |
7 | idleTimeout="Infinite" |
8 | shutDownTimeout="00:00:05" |
9 | requestLimit="Infinite" |
10 | requestQueueLimit="5000" |
11 | restartQueueLimit="10" |
12 | memoryLimit="40" |
13 | webGarden="false" |
14 | cpuMask="0xffffffff" |
15 | userName="System" |
16 | password="autogenerate" |
17 | logLevel="Errors" |
18 | clientConnectedCheck="00:00:05" |
19 | comAuthenticationLevel="Default" |
20 | comImpersonationLevel="Default" |
21 | responseDeadlockInterval="00:03:00" |
22 | responseRestartDeadlockInterval="00:09:00" |
23 | maxWorkerThreads="25" |
24 | maxIoThreads="25" |
25 | serverErrorMessageFile="" |
26 | pingFrequency="00:00:30" |
27 | pingTimeout="00:00:05" |
28 | /> |
29 | </system.web> |
30 | </configuration> |
设置项明细表:
# | Attribute | Settings | Default |
1. | enable | true | false | true |
2. | timeout | Infinite | HH:MM:SS | Infinite |
3. | idleTimeout | Infinite | HH:MM:SS | Infinite |
4. | shutDownTimeout | HH:MM:SS | 00:00:05 |
5. | requestLimit | Infinite | int | Infinite |
6. | requestQueueLimit | int | 5000 |
7. | restartQueueLimit | int | 10 |
8. | memoryLimit | int | 40 |
9. | webGarden | true | false | false |
10. | cpuMask | bit mask | 0xffffffff |
11. | userName | user | System | Machine | System |
12. | password | autogenerate | password | autogenerate |
13. | logLevel | All | None | Errors | Errors |
14. | clientConnectedCheck | HH:MM:SS | Infinite | 00:00:05 |
15. | comAuthenticationLevel | Default | None | Connect | Call | Pkt | PktIntegrity | PktPrivacy | Default |
16. | comImpersonationLevel | Default | Anonymous | Identify | Impersonate | Delegate | Default |
17. | responseDeadlockInterval | Infinite | HH:MM:SS | 00:03:00 |
18. | responseRestartDeadlockInterval | Infinite | HH:MM:SS | 00:09:00 |
19. | maxWorkerThreads | int | 25 |
20. | maxIoThreads | int | 25 |
21. | serverErrorMessageFile | filename | --- |
22. | pingFrequency | HH:MM:SS | 00:00:30 |
23. | pingTimeout | HH:MM:SS | 00:00:05 |
启用ASP.NET独立进程
1 | ... |
2 | <processModel |
3 | enable="true" |
4 | ... |
enable设置指示ASP.NET应该启用它的独立进程而不是运行在IIS进程中。该项缺省的值是true(启用独立进程)。如果为false(在IIS进程中运行),后续的设置将会被忽略。
自动重启ASP.NET进程
有5种方法可以重启ASP.NET进程
1 | ... |
2 | <processModel |
3 | timeout="168:00:00" |
4 | ... |
通过timeout设置项,在运行了指定的时间后重新创建一个新的进程实例。在上面的设置中在运行了168小时后(1周)会重新创建一个进程以取代现有的进程。不过需要注意的是,计时是当接收到第一个请求时,因为ASP.NET的进程是在处理第一个请求时创建的。这个设置非常有用,如果程序中有轻微的内存泄漏而需要周期性的重置IIS。
1 | ... |
2 | <processModel |
3 | requestLimit="10000" |
4 | ... |
通过requestLimit设置项,在处理了指定数量的请求后,创建一个新的进程。这个对Web服务器的性能是由于处理了过多的请求后降低非常有帮助。
1 | ... |
2 | <processModel |
3 | memoryLimit="50" |
4 | ... |
通过memoryLimit设置项,比如50,这意味着当进程使用的内存占到系统总的内存的50%时,进程会被取消,而一个新的进程会创建出来,所有现有的请求会由这个新的进程进行处理。这个对内存泄漏非常有帮助。
1 | ... |
2 | <processModel |
3 | responseDeadlockInterval="00:03:00" |
4 | ... |
通过responseDeadlockInterval设置项,比如3分钟,当有新的请求但没有任何响应超过3分钟时,重新启动进程。
1 | ... |
2 | <processModel |
3 | pingFrequency="00:00:30" |
4 | pingTimeout="00:00:05" |
5 | ... |
通过pingFrequency和pingTimeout设置项,系统会在pingFrequency指定的周期内探询ASP.NET进程,如果在pingTimeout时间内没有响应,重启该进程。
停止ASP.NET进程
有两个方法可以自动停止进程
1 | ... |
2 | <processModel |
3 | idleTimeout="00:30:00" |
4 | ... |
通过idleTimeout设置项,如果在指定的时间内没有任何请求,进程会自动退出。在一个新的请求到来后,再重新启动进程。
1 | ... |
2 | <processModel |
3 | shutDownTimeout="00:00:05" |
4 | ... |
通过shutDownTimeout设置项,当ASP.NET进程需要退出但是失败后,系统会在等待指定的时间后强行终止该进程。
用户连接状态检查
1 | ... |
2 | <processModel |
3 | clientConnectedCheck="00:00:05" |
4 | ... |
在Web服务器响应比较慢时,用户可能会重复点击同一个URL。这样会增加服务器负担。甚至用户可能会取消请求,但是服务器可能还在处理该用户的请求队列。为此,我们可以指示服务器检查用户的连接状态,如果用户已经不在线,清除该用户所有的请求。在上面的设置中,服务器每5秒会检查每个在队列中的请求,如果用户已经离线,服务器会清除该请求。
结论
ASP.NET现在工作在一个独立的进程中。我们可以通过machine.config配置文件来使得该进程更加稳定和高效。
一、应用身份验证、但个别目录或文件不需要身份验证
最常见的是一个网站的后台需要验证,而前台是不需要的;一般登录页面会有验证码、而生成验证码那个页面是不需要验证的、否则验证图片是显示不出来的。
解决方法:
<!-- 身份验证 -->
<authentication mode="Forms">
<forms name=".myForm" loginUrl="login.aspx" timeout="20" protection ="All"/>
</authentication>
<authorization >
<deny users ="?"/>
</authorization>
</system.web>
<!-- 验证码 -->
<location path ="CheckCode.aspx">
<system.web >
<authorization >
<allow users ="*"/>
</authorization>
</system.web>
</location>
使用身份验证、禁止匿名用户访问,同时对页面checkcode.aspx允许所有用户访问、即不用验证。
二、改写(不需求)web.config继承
假设IIS中有个站点A、而A站点下面有个虚拟目录B、此时可以输入:"ttp://ip址/" 访问到A站点,输入http://ip地址/B 访问到B网站;而B项目中的web.config首先会继承A站点的web.config,如果A的config有很多设置如<httpModules>,<page>等,而B项目的config没有这些设置,项目也没用到这些设置,但B的程序在运行时确会出错、原因就是它继承A的config;这个让人有点讨厌“我压根没用它、怎么会有错?且提示出错的那个文件是A的config”,可以这样解决:
A项目用到了主题
B项目不用
让B的主题为空、否则B运行时提示找不到default主题目;
A的设置
<add name="SiteCache" type="SiteCache"/>
</httpModules>
B的设置(不用的项,清除)
<clear/>
</httpModules>
如果A.B都用到
<add key="app" value="" />
</appSettings>
B运行时会提示app已经加载,此时可以
<remove name="app" />
<add key="app" value="" />
</appSettings>
或者:
<clear />
<add key="app" value="" />
</appSettings>
三、禁止web.config重写
同上面的例子、如果B中的config设置必须与A中的相同,不能重写,则A的config设置
<system.web>
<httpModules>
<add name="SiteCache" type="SiteCache"/>
</httpModules>
</system.web>
</location>
此时B的config中<httpModules>设置不能改写,须和A的设置相同。
作者:ChenLuLouis
出处:http://www.cnblogs.com/chenlulouis/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-chenlulouisBlog。
posted on 2010-05-26 11:14 chenlulouis 阅读(15020) 评论(1) 编辑 收藏 举报