原因之前看了很多帖子，其實(shí)能肯定就是非webman的問(wèn)題，主要是想看看有什么手段定位具體產(chǎn)生原因，業(yè)務(wù)日志1天就幾十MB了，通過(guò)業(yè)務(wù)日志定位相對(duì)難，而且這個(gè)是偶現(xiàn)問(wèn)題，即如果我用相同條件去發(fā)起請(qǐng)求，不一定就busy，但10次有2~3次會(huì)出現(xiàn)BUSY。就如下面回復(fù)到的，猜測(cè)是帶寬問(wèn)題，但還是想確認(rèn)下。

好的謝謝，主要是想找出“慢業(yè)務(wù)”，另外就是想確認(rèn)下，如果發(fā)送不及時(shí)會(huì)否導(dǎo)致產(chǎn)生busy？因?qū)嶋H上那臺(tái)服務(wù)器上跑了兩個(gè)類似這樣的服務(wù)（兩個(gè)單獨(dú)的webman），QPS合計(jì)估計(jì)50~60，但是服務(wù)器帶寬只有5M，平均每次請(qǐng)求返回包大小10KB，所以猜測(cè)是否因?yàn)槌隹趲挻驖M，導(dǎo)致出現(xiàn)進(jìn)程BUSY，這個(gè)可能性會(huì)有嗎？

如果是每秒60個(gè)10KB的包，帶寬基本上就滿了

想找出慢業(yè)務(wù),最直接的方式是記錄每個(gè)請(qǐng)求的實(shí)行時(shí)間,看status沒(méi)用

量過(guò)大，實(shí)際情況很難篩選出過(guò)慢的請(qǐng)求，但是這一步其實(shí)也做了，但是就如上面回復(fù)的，通過(guò)相同參數(shù)重發(fā)請(qǐng)求也無(wú)法100%復(fù)現(xiàn)這個(gè)問(wèn)題，想到畢竟還有其他因素的存在，例如busy時(shí)數(shù)據(jù)庫(kù)是否繁忙，內(nèi)網(wǎng)是否有波動(dòng)等客觀因素，但結(jié)合已有信息猜測(cè)是帶寬問(wèn)題，只是無(wú)法進(jìn)一步確定

BaseController的beforeAction記錄起始時(shí)間,afterAction記錄結(jié)束時(shí)間,所有Controller都會(huì)自動(dòng)調(diào)用