IIS并发瓶颈,有几个地方,IIS线程池的最大队列数,工做进程数,最大并发数。这些这里就不展开。主要是最近由于过分使用Task 致使的线程数占用过多,因此实验了一下 .net线程池 的限制,分享一下。并发
注意IIS线程池与.NET线程池不是同一个东西,下面详解。工具
当处于内核模式的http.sys接收到来自用户的请求以后,会将请求放入队列中。那处于用户模式的w3wp进程如何从内核模式的队列中取出请求呢?性能
w3wp中有专门干这个的——w3dt+w3tp。ui
当请求被w3tp经过w3dt从http.sys的队列中取出来后,接下来的工做就会转交给ASP.NET,线程池——.NET Thread Pool。spa
为了检验.net 线程池 最大线程数的限制,在MVC中新增一个Action 以下.net
每一个task sleep 1s ,这样线程池就会被占用最多20W条线程。线程
设置.net线程池 的配置文件位置3d
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.configblog
64位系统:队列
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config
找到这个节点 processModel
设置maxWorkerThreads =20
autoConfig=false (win10默认是true)
访问地址:/home/TestTaskLimitCount 时
使用工具集 SysinternalsSuite procexp64.exe 查看系统进程的详细信息
看到W3WP.EXE 这里的总线程数卡在100左右,由于我这里的4个CPU,因此maxWorkerThreads *CPUCOUNT =80 另外的27条线程多是IIS线程池里的。
而后当咱们同时访问该站点其余URL时,所有都在一直在等待了。
OK,从新改成
maxWorkerThreads =200
这个时候从新启动站点,运行/home/TestTaskLimitCount 时,看到线程数很快累加到400-500之间,这个时候线程池并无被用满,只是有些Task任务结束后丢回线程池后又被从新启用。
同时再次访问一下该站点其余URL,发现虽然加载速度稍有缓慢,可是OK没问题的。
这个值(WorkerThreads)最好根据机器性能自行配置,通常100左右,minWorkerThreads 也很重要,由于开启线程的速度其实还挺慢的,每秒能够开启几条而已,因此预先设置好minWorkerThreads,能够预防一些突发流量。