問題描述：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】），其次配置合理的最大進程數。

?

轉載于:https://www.cnblogs.com/TeemoHQ/p/9856919.html

總結

以上是生活随笔為你收集整理的Asp.net 性能监控之压测接口“卡住” 分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。