.Net Framework线程优化
ASP.NET可用的线程毕竟是有限的，可能是当时瞬间的并发请求太多，ASP.NET来不及创建足够的线程处理这些请求。
我们来看一下.Net framework中线程相关的设置
machine.config中的processModel（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）
有4个相关设置：maxWorkerThreads（默认值是20）, maxIoThreads（默认值是20）, minWorkerThreads（默认值是1）, minIoThreads（默认值是1）。（这些设置是针对每个CPU核）
我们用的就是默认设置，由于我们的Web服务器是8核的，于是实际的maxWorkerThreads是160，实际的maxIoThreads是160，实际的minWorkerThreads是8，实际的minIoThreads是8。
基于这样的设置，是不是如果瞬间并发请求是169，就会出现排队？不是的，ASP.NET没这么傻！因为CLR 1秒只能创建2个线程（"The CLR ThreadPool injects new threads at a rate of about 2 per second. "），等线程用完时才创建，黄花菜都凉了。
我们猜测ASP.NET只是根据这个设置去预测线程池中的可用线程是不是紧张，是不是需要创建新的线程，以及创建多少线程。
假如并发请求数平时是300，突然某个瞬间并发请求数是600，超出了ASP.NET预估的所需的可用线程数，于是那些拿不到线程的请求只能排队等待正在执行的请求释放线程以及CLR创建新的线程。
随着时间的推移，释放出来的线程+新创建的线程足以处理这些排队的请求，就恢复了正常。
优化设置
<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="2000" maxIoThreads="1000" minWorkerThreads="150" minIoThreads="150"/>