ASP.NET并行处理的步骤



ASP.NET并行处理的步骤

 　　ASP.NET是如何在IIS中工作的一文已经很详细的介绍了一个请求是如何从客户端到服务器的HTTP.SYS最后进入CLR进行处理的（强烈建议不了解这一块的同学先看这篇文章，有助于你理解本小节），但是所有的步骤都是基于一个线程的假设下进行的。IIS本身就是一个多线程的工作环境，如果我们从多线程的视角来看会发生什么变化呢？我们首先来看一下下面这张图。注意：我们下面的步骤是建立在IIS7.0以后的集成模式基础之上的。（注：下面这张图在dudu的提醒之后，重新做了一些搜索工作，做了一些改动，w3dt这一步来自于博客园团队对问题的不断探索，详情可以点这里）

　　我们再来梳理一下上面的步骤：

1. 所有的请求最开始是由HTTP.SYS接收的，HTTP.SYS内部有一个队列维护着这些请求，这个队列的request的数量大于一定数量（默认是1000）的时候，HTTP.SYS就会直接返回503状态（服务器忙），这是我们的第一个阀门。性能计数指标：“Http Service Request Queues\CurrentQueueSize”
2. 由w3dt负责把请求从HTTP.SYS 的队列中放到一个对应端口的队列中，据非官方资料显示该队列长度为能为20（该队列是非公开的，没有文档，所以也没有性能计数器）。
3. IIS 的IO线程从上一步的队列中获取请求，如果是需要ASP.NET处理的，就会转交给CLR 线程池的Worker 线程，IIS的IO线程继续返回重复做该步骤。CLR 线程池的Worker线程数量是第二个阀门。
4. 当CLR中正在被处理的请求数据大于一定值（最大并行处理请求数量，.NET4以后默认是5000）的时候，从IO线程过来的请求就不会直接交给Worker线程，而是放到一个进程池级别的一个队列了，等到这个数量小于临界值的时候，才会把它再次交给Worker线程去处理。这是我们的第三个阀门。
5. 上一步中说到的那个进程池级别的队列有一个长度的限制，可以通过web.config里面的processModel/requestQueueLimit来设置。这可以说也是一个阀门。当正在处理的数量大于所允许的最大并行处理请求数量的时候，我们就会得到503了。可以通过性能计数指标：“ASP.NET v4.0.30319\Requests Queued” 来查看该队列的长度。

 哪些因素会控制我们的响应能力

　　从上面我们提到了几大阀门中，我们可以得出下面的几个数字控制或者说影响着我们的响应能力。

1. HTTP.SYS队列的长度
2. CLR线程池最大Worker线程数量
3. 最大并行处理请求数量
4. 进程池级别队列所允许的长度

HTTP.SYS队列的长度

　　这个我觉得不需要额外解释，默认值是1000。这个值取决于我们我们后面IIS IO线程和Worker线程的处理速度，如果它们两个都处理不了，这个数字再大也没有用。因为最后他们会被存储到进程池级别的队列中，所以只会造成内存的浪费。

最大Worker线程数量

　　这个值是可以在web.config中进行配置的。

　　maxWorkerThreads: CLR中真实处理请求的最大Worker线程数量
　　minWorkerThreads:CLR中真实处理请求的最小Worker线程数量

　　minWorkerThreads的默认值是1，合理的加大他们可以避免不必要的线程创建和销毁工作。

最大并行处理请求数量

　　进程池级别的队列给我们的CLR一定的缓冲，这里面要注意的是，这个队列还没有进入到CLR，所以它不会占用我们托管环境的任何资源，也就是把请求卡在了CLR的外面。我们需要在aspnet.config级别进行配置，我们可以在.net fraemwork的安装目录下找到它。一般是 C:\Windows\Microsoft.NET\Framework\v4.0.30319 如果你安装的是4.0的话。

　　maxConcurrentRequestPerCPU: 每个CPU所允许的最大并行处理请求数量，当CLR中worker线程正在处理的请求之和大于这个数时，从IO线程过来的请求就会被放到我们进程池级别的队列中。
　　maxConcurrentThreadsPerCPU: 设置为0即禁用。
　　requestQueue: 进程池级别队列所允许的长度。　　

async和await 做了什么？

　　我们终于要切入正题了，拿ASP.NET MVC举例，如果不采用async的Action，那么毫无疑问，它是在一个Woker线程中执行的。当我们访问一些web service，或者读文件的时候，这个Worker线程就会被阻塞。假设我们这个Action执行时间一共是100ms，其它访问web service花了80ms，理想情况下一个Worker线程一秒可以响应10个请求，假设我们的maxWorkerThreads是10，那我们一秒内总是可响应请求就是100。如果说我们想把这个可响应请求数升到200怎么做呢？

　　有人会说，这还不简单，把maxWorkerThreads调20不就行了么？ 其实我们做也没有什么 问题，确实是可以的，而且也确实能起到作用。那我们为什么还要大费周章的搞什么 async/await呢？搞得脑子都晕了？async/await给我们解决了什么问题？它可以在我们访问web service的时候把当前的worker线程放走，将它放回线程池，这样它就可以去处理其它的请求了。等到web service给我们返回结果了，会再到线程池中随机拿一个新的woker线程继续往下执行。也就是说我们减少了那一部分等待的时间，充份利用了线程。

　   我们来对比一下使用async/awit和不使用的情况，

　　不使用async/await： 20个woker线程1s可以处理200个请求。

　　那转换成总的时间的就是 20 * 1000ms =  20000ms，
　　其中等待的时间为 200 * 80ms = 16000ms。
　　也就是说使用async/await我们至少节约了16000ms的时间，这20个worker线程又会再去处理请求，即使按照每个请求100ms的处理时间我们还可以再增加160个请求。而且别忘了100ms是基于同步情况下，包括等待时间在内的基础上得到的，所以实际情况可能还要多，当然我们这里没有算上线程切换的时间，所以实际情况中是有一点差异的，但是应该不会很大，因为我们的线程都是基于线程池的操作。
　　所有结果是20个Worker线程不使用异步的情况下，1s能自理200个请求，而使用异步的情况下可以处理360个请求，立马提升80%呀！采用异步之后，对于同样的请求数量，需要的Worker线程数据会大大减少50%左右，一个线程至少会在堆上分配1M的内存，如果是1000个线程那就是1G的容量，虽然内存现在便宜，但是省着总归是好的嘛，而且更少的线程是可以减少线程池在维护线程时产生的CPU消耗的。另：dudu分享 CLR1秒之内只能创建2个线程。

　　注意：以上数据并非真实测试数据，真实情况一个request的时间也并非100ms，花费在web service上的时间也并非80ms，仅仅是给大家一个思路:)，所以这里面用了async和await之后对响应能力有多大的提升和我们原来堵塞在这些IO和网络上的时间是有很大的关系的。

几点建议

　　看到这里，不知道大家有没有得到点什么。首先第一点我们要知道的是async/await不是万能药，不们不能指望光写两个光键字就希望性能的提升。要记住，一个CPU在同一时间段内是只能执行一个线程的。所以这也是为什么async和await建议在IO或者是网络操作的时候使用。我们的MVC站点访问WCF或者Web Service这种场景就非常的适合使用异步来操作。在上面的例子中80ms读取web service的时间，大部份时间都是不需要cpu操作的，这样cpu才可以被其它的线程利用，如果不是一个读取web service的操作，而是一个复杂计算的操作，那你就等着cpu爆表吧。

　　第二点是，除了程序中利用异步，我们上面讲到的关于IIS的配置是很重要的，如果使用了异步，请记得把maxWorkerThreads和maxConcurrentRequestPerCPU的值调高试试。