问题描述：web api项目接口压测。前期并发100，500没出现问题，平均耗时也在几百毫秒。当并发1000时候，停留等待许久，看现象是jemeter卡住，没返回，时间过了许久，才正常。
解决过程：
查看服务器应用程序日志，查看项目全局捕获日志，查看服务器cpu，内存，网络。一切正常
查看客户端和服务端之间的Tcp连接：netstat -ano | find /c "***.***.***.***"，连接一直处于通信状态一直没有释放。卡住剩余的连接数和没释放的连接数相同。好像有点端倪了，但是很模糊。
既然连接一直没有释放那么尝试把Tcp的timewait时间变短。修改注册表的配置。然而并没有什么用。
无头绪，只好加大监控力度。Windows performance Counters 。
运维搞了个Telegraf+Influxdb+Grafana，Telegraf的counters配置 地址，当然也可以选择cmd运行perfmon查看windows自带的性能监视器。
发现压测时候Request Queue突然增加很多，Requests/Sec下降，
查找资料，看到博客园团队在14年就遇到相似问题：云计算之路-阿里云上：从ASP.NET线程角度对"黑色30秒"问题的全新分析
还有一篇外文说的更加详细，很多监控细节都有说明。地址。 修改了ProcessModel之后压测果然不会出现卡住的情况
大致意思就是：瞬间的并发请求太多，Asp.net预留线程不够，Asp.net来不及创建足够新的线程。
当然这个可以配置：machine.config中的processModel（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）
注意：ProcessModel这个配置在项目的web.config也可以智能提示出来，但是配置了也无效。只能在machine配置。说明地址
其次。还有解决办法，把IIS项目的应用程序池 进程数量调大，把队列长度也调大。并发压测的时候先预热请求几个接口让进程都起来先。
虽然不会卡，但是物极必反。太多进程同时跑起来，CPU一下子就上去了。（图中在14:02和14：05设置的进程数量不同）。
疑问：修改的ProcessModel的配置是全局的，不能单个项目配置，那么一台服务器是多个项目，会不会有影响
最终修改方法：优化接口业务代码（辛亏还可以优化【HttpWebRequest的DefaultConnectionLimit】），其次配置合理的最大进程数。