提高ASP.NET性能与可伸缩性的几个个常用方法剖析
在ASP.NET中,有很多提高性能和可伸缩性的方法,本篇就为朋友们介绍7个,朋友们可以适当的应用在项目之中。
本篇的议题如下:
ASP.NET管道优化
ASP.NET处理配置的优化
 
ASP.NET管道优化
 
               我们知道,在ASP.NET的处理机制的设计是基于管道模型的,ASP.NET的管道中,有很多的HttpModule。每个要处理的请求经过ASP.NET管道的时候,都会被其中的HttpModule拦截,进行相关的处理之后,再将请求发送给下一个HttpModule。例如,SessionStateModule会拦截请求,并且解析请求中的Session Cookie,然后加载合适的Session到HttpContext中(要知道,每一个Session都会有一个保存在Cookie中的Session Key)。
 
               同时,并且不是在管道中的所有的HttpModule都是必须的,例如,如果我们没有在项目中使用Membership和Profiler Provider,那么没我们就没有必要使用FormsAuthenticate模块,再如,如果我们没有使用Windows 身份验证,那么,我们就可以移除WindowsAuthenticate模块。
 
               在默认情况下,每次ASP.NET运行时在启动的时候,都会根据配置文件去加载相应的HttpModule,根据IIS的版本不同,要查看的配置文件也不一样。
 
               对于IIS 6而言,默认的定义了加载HttpModule的文件就是machine.config(位于:
$WINDOWS$\Microsoft.NET\Framework\$VERSION$\CONFIG)。
 
               对于IIS 7(以及以后版本),默认的配置文件是applicationHost.config(位于:%SystemRoot%\system32\inetsrv)
 
               我们这里以IIS 6为例子,machine.config配置如下:
 
20120329095716.png
 
               我们可以在我们站点的web.config移除我们不需要的Module,如下:
 
20120329095752.png
 
 
ASP.NET处理配置的优化
 
               ASP.NET处理模型的配置定义了一些ASP.NET在处理请求的时候的一些特性,例如开启多少个线程进行请求的处理,每一个请求处理线程的过期时间时候多少等。
 
               很多的时候,需要我们自己根据实际情况去修改默认的配置,特别是随着现在硬件变得越来越便宜和功能越来越强大,对配置对相应的修改,可以极大的提升站点的性能。
 
               以IIS 6而言,默认的处理模型的配置文件依然在machine.config中,如下:
 
20120329095834.png
 
               对于IIS 7而言,配置在applicationHost.config,其中,节点的名称和IIS 6一样。
               这里,我们依然以IIS 6为例子,如下:
20120329095937.png
 
               首先,看到如此众多的配置项不要惊慌,要淡定,因为其中每一个项都是非常有用的。下面我们就挑几个比较常用的,也是重点的来看看。
               maxWorkerThreads:这个可以说是见名知意了,就是每一个站点的线程池可以启动的最多的处理线程的数目。在IIS 6中,每一个逻辑可以开启的最大线程数目是20个,双核的CPU那就是40个了。
 
               如果我们的服务器的配置不错,我们可以将这个数目变大一点,例如100等。这里需要注意的就是,我们要根据实际的情况要配置这个数目,但是我们有一些大致的指导方针:每个线程的开启需要大约4M的内存,如果我们的服务器的物理内存是2G,那么在理论上,我们是可以同时跑500的处理线程的。
 
               但是很多时候,我们的服务器的内存不可能全部用在这里。因为服务器上面的内存要被用在内核模式和用户模式。所谓的内核模式,就是Windows内部核心的操作,例如管理线程,进程,管理I/O设备的驱动等。用户模式就是除了内核模式以外的操作,例如位来自用户应用程序的请求提供服务,包括IIS,SQL Server等。所有用户模式的应用程序通过运行在内核模式的执行层访问资源,例如,如果应用程序要进行磁盘的I/O,那么该请求就会提交到内核模式的执行层,由它来执行请求并且将结果返回给发出请求的用户模式的进程。
 
这里面的东西很多,我们就不扯远了。还是言归正传。
 
               如果我们的一个ASP.NET的站点应用不是消耗CPU的操作的应用,那么,我们可以适当的增加更多的处理线程。例如,如果我们的应用程序只要是为外界提供Web服务,或者进行文件的上传和下载,而这些操作对CPU的压力不大,这个时候,我们可以配置更多的处理线程。
 
              这里有一点需要注意的就是:尽管,我们配置了100个或者更多,也不见得这100线程就会理解使用,而且还有一个负面的作用就是:线程越多,CPU调度就越复杂。这里我想起了之前有朋友问我一个问题:我们已经配置了最大的处理线程是1000,为什么我们的站点的并发处理能力没有达到1000呢?我当是给这个一个最简单的回复:你手里有了1000万元,你会一下子全部花完吗?CPU也是这样,通过配置maxWorkerThreads,我们告诉服务器,最大的限度可以到某个数目,但是不见得服务器就一定按照这个最大的限度来,因为有很多的东西需要服务器去考虑和计算,例如之前的内存问题,等。
 
另外,如果ASP.NET线程池中没有可以用来处理请求的线程,那么之后发给站点的请求就会加入到等待队列中。
需要大家配置之后,多多的进行测试。
               另外,为大家给出下面的一个处理线程数目的表格,进行参考:
20120329100045.png
 
               maxIOThreads:默认是每个逻辑处理有20个线程。I/O处理线程用来处理对I/O的请求,例如对文件的读和写的操作,数据库的操作,Web Service的调用。在设置这个配置的时候,需要考虑站点中文件的上传、下载的情况,考虑的要点可以参考上面的maxWorkderThreads,另外需要注意的就是,文件的上传、下载是一个非常消耗内存与磁盘的操作,如果站点有很多的文件要上传写入和下载,那么建议重新用另外的服务器去处理,并且将相关的文件缓存在内存中,即,搭建文件缓存服务器。
 
              memoryLimit:配置在IIS 6中w3pw.exe进程可以使用的最大的内存容量,这是一个百分比值。如果站点的处理进程使用内存超过了这个容量限制,那么IIS就会重新的启动一个进程,并且将请求给这个新的进程,原先的旧的进程就被杀死了(注:这里说的是进程)。如果我们的服务器上只运行一个ASP.NET的站点,而且没有其他消耗内存的应用,那么,我们可以尝试将这个配置改为80(即,服务器RAM的80%)。
 
              如果我们的服务器上面有可能导致内存泄露的应用在运行,例如在应用中有COM组件等,那么可以把这个配置值设置的小一点,这样就可以在站点发生了内存泄露问题之后,我们的处理进程可以快速的被杀死,从而回收一些内存资源。当然,这种设置最小值的的方法只是一个临时的解决方案,最终还需我们去彻底的解决内存泄露问题。
 
               除了可以设置processModel之外,我们还可以设置其他的配置,例如:system.net节点,我们可以设置一个IP地址的最大的请求连接数(默认是2),如下: 
20120329100139.png
               今天就暂时到这里!