問(wèn)題描述：web api項(xiàng)目接口壓測(cè)。前期并發(fā)100，500沒(méi)出現(xiàn)問(wèn)題，平均耗時(shí)也在幾百毫秒。當(dāng)并發(fā)1000時(shí)候，停留等待許久，看現(xiàn)象是jemeter卡住，沒(méi)返回，時(shí)間過(guò)了許久，才正常。

解決過(guò)程：

查看服務(wù)器應(yīng)用程序日志，查看項(xiàng)目全局捕獲日志，查看服務(wù)器cpu，內(nèi)存，網(wǎng)絡(luò)。一切正常

查看客戶端和服務(wù)端之間的Tcp連接：netstat -ano | find /c "***.***.***.***"，連接一直處于通信狀態(tài)一直沒(méi)有釋放。卡住剩余的連接數(shù)和沒(méi)釋放的連接數(shù)相同。好像有點(diǎn)端倪了，但是很模糊。

既然連接一直沒(méi)有釋放那么嘗試把Tcp的timewait時(shí)間變短。修改注冊(cè)表的配置。然而并沒(méi)有什么用。

無(wú)頭緒，只好加大監(jiān)控力度。Windows performance Counters 。

運(yùn)維搞了個(gè)Telegraf+Influxdb+Grafana，Telegraf的counters配置 地址，當(dāng)然也可以選擇cmd運(yùn)行perfmon查看windows自帶的性能監(jiān)視器。

發(fā)現(xiàn)壓測(cè)時(shí)候Request Queue突然增加很多，Requests/Sec下降，

查找資料，看到博客園團(tuán)隊(duì)在14年就遇到相似問(wèn)題：云計(jì)算之路-阿里云上：從ASP.NET線程角度對(duì)"黑色30秒"問(wèn)題的全新分析

還有一篇外文說(shuō)的更加詳細(xì)，很多監(jiān)控細(xì)節(jié)都有說(shuō)明。地址。? ? ? ? ?修改了ProcessModel之后壓測(cè)果然不會(huì)出現(xiàn)卡住的情況

大致意思就是：瞬間的并發(fā)請(qǐng)求太多，Asp.net預(yù)留線程不夠，Asp.net來(lái)不及創(chuàng)建足夠新的線程。

當(dāng)然這個(gè)可以配置：machine.config中的processModel（位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config）

注意：ProcessModel這個(gè)配置在項(xiàng)目的web.config也可以智能提示出來(lái)，但是配置了也無(wú)效。只能在machine配置。說(shuō)明地址

?

其次。還有解決辦法，把IIS項(xiàng)目的應(yīng)用程序池 進(jìn)程數(shù)量調(diào)大，把隊(duì)列長(zhǎng)度也調(diào)大。并發(fā)壓測(cè)的時(shí)候先預(yù)熱請(qǐng)求幾個(gè)接口讓進(jìn)程都起來(lái)先。

雖然不會(huì)卡，但是物極必反。太多進(jìn)程同時(shí)跑起來(lái)，CPU一下子就上去了。（圖中在14:02和14：05設(shè)置的進(jìn)程數(shù)量不同）。

?

疑問(wèn)：修改的ProcessModel的配置是全局的，不能單個(gè)項(xiàng)目配置，那么一臺(tái)服務(wù)器是多個(gè)項(xiàng)目，會(huì)不會(huì)有影響

?

最終修改方法：優(yōu)化接口業(yè)務(wù)代碼（辛虧還可以優(yōu)化【HttpWebRequest的DefaultConnectionLimit】），其次配置合理的最大進(jìn)程數(shù)。

?

轉(zhuǎn)載于:https://www.cnblogs.com/TeemoHQ/p/9856919.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。