IIS并发瓶颈，有几个地方，IIS线程池的最大队列数，工作进程数，最大并发数。这些这里就不展开。主要是最近因为过度使用Task 导致的线程数占用过多，所以实验了一下 .net线程池 的限制，分享一下。
注意IIS线程池与.NET线程池不是同一个东西，下面详解。
当处于内核模式的http.sys 接收到来自用户的请求之后，会将请求放入队列中。那处于用户模式的w3wp 进程如何从内核模式的队列中取出请求呢？
w3wp 中有专门干这个的——w3dt+w3tp 。
当请求被w3tp 通过w3dt 从http.sys 的队列中取出来后，接下来的工作就会转交给ASP.NET ，线程池——.NET Thread Pool 。
为了检验.net 线程池 最大线程数的限制，在MVC 中新增一个Action 如下
每个task sleep 1s ，这样线程池就会被占用最多20W 条线程。
设置.net 线程池 的配置文件位置
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config\machine.config
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 ，可以预防一些突发流量。
Original: https://www.cnblogs.com/7rhythm/p/9964543.html
Author: 鬼柒
Title: .NET线程池最大线程数的限制-记一次IIS并发瓶颈
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/568630/
转载文章受原作者版权保护。转载请注明原作者出处！