如何配置IIS处理多并发请求及存在的问题
IBM刀片服务器，Intel至强处理器，4物理核，16个逻辑核心，内存32G
Windows Server2008 Enterprise R2， ASP.NET 4.0 Webform IIS7.5 集成模式
当发现请求明显延迟，没有被即时处理的现象，首先就要查看Windows自带的性能日志Performance Monitor。
由于我注意到只有对于.aspx或.ashx的请求才会延迟，而.htm或.jpg文件都是即时响应的，所以很明显问题出在ASP.NET上，于是我选择了性能监视器中的ASP.NET 4.0中的2个主要计数器：Requests Current（当前请求数）, Requests Queued（被排队的请求数）进行观察。通过观察发现，当前请求数达到200左右时，被排队的请求数就从0开始上升，一直到50左右，如果请求数继续上升，则被排队数也随之上升。当被排队的请求数>0时，就意味着这个时候去访问任何.aspx页面，页面都会处于长时间等待中，没有任何响应，直到IIS处理完了其他请求，才会开始处理队列中的请求。也就是说，当排队数长期>0时，系统基本处于不可用的状态。
由于这个系统的页面布局比较复杂，采用了大量的Ajax+.ashx的方式，将内容分批展示在页面上，所以对服务器的请求总数会比传统aspx模式来的多一些，一个页面全部加载完毕可能需要5-10秒，但我想这不应该是造成问题的主要原因，就算系统性能较差，IIS也应该足以承受这么小的并发量的。
为探究到底是系统写的有问题，还是IIS本身的问题，我抛开我们的系统，写了一个简单的页面，就一个aspx文件，page_load里sleep 10秒。假设这就是一个性能比较差的网站，每个页面都要10秒才能展现，我将其部署在IIS上测试其性能，我使用的是Microsoft Web Application Stress Tool，模拟发起80个线程，每个连接有4个Socket，总共相当于320个并发请求。
测试开始后，可以从下图中看到，当前请求数立刻攀升到300左右（图中红线），然后队列中的请求数也上升到300左右（图中绿线），就是说在300个并发请求下，几乎所有的请求都被排队了，系统基本不可用，通过简单的测试，这个问题已经得以重现了。
随着时间推移，发现绿线慢慢减少，从300下降到100多，就是系统可用性渐渐提高，有一部分用户可以正常使用，但大部分还在排队。
过了6，7分钟，队列中的请求数下降到0左右，并有一些小幅波动。这个时候大部分请求可以被正常处理了。 按照这个现象分析的话，应该是IIS发现有大量请求在队列中，就会试图增加处理线程数以满足要求，但是增长速度有些缓慢。
那是不是系统经过了6，7分钟的适应期之后，以后就一直可以在这个并发量下稳定运作了呢？事实并非如此。我将压力测试停了几秒，当服务器的请求数降为0以后，再重新开启320个请求的测试，IIS如何表现？从下图可以看到，只要请求数有明显上升，则等待队列又开始达到最高值，然后缓慢下降，重复上面的过程。总结下来就是，当出现较大并发时，IIS的处理请求能力完全跟不上，需要很长时间才能开出足够的线程。
然后我做了一个测试，看看IIS默认情况到底能承受多少请求而不排队？似乎是在100个并发左右，表现尚可，未出现排队。
当200个左右就不行了。
然后我将测试程序从sleep10秒改成3秒，对于一个应用系统来说，页面平均3秒处理时间的性能该还算比较正常了。但可惜的是，排队现象与处理时间并无太大关系，排队仍然很严重。
针对以上问题，查阅了相关资料，是否出现排队是和应用程序池的可用线程有关，通过2个方法可以查看系统总线程数和当前可用线程数。
ThreadPool.GetAvailableThreads( out availableWorker, out availableIO);
ThreadPool.GetMaxThreads(out maxWorker, out maxIO);
在队列请求数达到120左右时，通过此方法，得到maxWorker=1600，而availableWorker=1472
因为服务器是16核的，ASP.NET4.0默认每核可以使用100个线程，所以maxWorker是1600，1600-120=1480，大致相等。
就是说当前有120个线程被用来处理请求，还有1400多个处于空闲。关键问题就是为什么这些空闲线程没有被及时启用？
ASP.NET提供的线程配置参数中，有一个参数是非常重要，但是可能被大家忽略的，就是minWorkerThreads。
