问题描述：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】），其次配置合理的最大进程数。