提高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配置如下：
我们可以在我们站点的web.config移除我们不需要的Module，如下：
ASP.NET处理配置的优化
ASP.NET处理模型的配置定义了一些ASP.NET在处理请求的时候的一些特性，例如开启多少个线程进行请求的处理，每一个请求处理线程的过期时间时候多少等。
很多的时候，需要我们自己根据实际情况去修改默认的配置，特别是随着现在硬件变得越来越便宜和功能越来越强大，对配置对相应的修改，可以极大的提升站点的性能。
以IIS 6而言，默认的处理模型的配置文件依然在machine.config中，如下：
对于IIS 7而言，配置在applicationHost.config，其中，节点的名称和IIS 6一样。
这里，我们依然以IIS 6为例子，如下：
首先，看到如此众多的配置项不要惊慌，要淡定，因为其中每一个项都是非常有用的。下面我们就挑几个比较常用的，也是重点的来看看。
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线程池中没有可以用来处理请求的线程，那么之后发给站点的请求就会加入到等待队列中。
需要大家配置之后，多多的进行测试。
另外，为大家给出下面的一个处理线程数目的表格，进行参考：
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），如下：
今天就暂时到这里！
本文转自yanyangtian51CTO博客，原文链接：http://blog.51cto.com/yanyangtian/822893
，如需转载请自行联系原作者
