Asp.net 性能監控之壓測接口「卡住」 分析

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