問題描述

前提：1.公司進(jìn)行一臺部署有http服務(wù)的壓測，第一天進(jìn)行了一晚上（10h）的測試(一次200并發(fā))，吞吐量大概56%左右。第二天（期間沒有重啟過tomcat）也進(jìn)行了一晚上（10h）測試(一次200并發(fā))，吞吐量卻降低至16%左右。環(huán)境一樣，為何落差那么大？2.我第一天壓測1000個并發(fā)時，線程數(shù)大概是1000+，但是第二天（期間沒有重啟過tomcat）壓測1000并發(fā)時，線程數(shù)卻降到700+，為何之前并發(fā)數(shù)和線程數(shù)成正比，后面卻不是了？

上述兩個前提，請問tomcat是有什么策略，還是jdbc連接池或者redis連接池導(dǎo)致以上現(xiàn)象嗎（使用G1回收機(jī)制）？

問題解答

這情況就復(fù)雜了，其復(fù)雜度取決于你的項目運(yùn)行環(huán)境、依賴哪些其他服務(wù)。如果你的壓測環(huán)境復(fù)雜（就是很多人都在你這臺服務(wù)器上運(yùn)行自己的東西），那壓測結(jié)果不穩(wěn)定是可以預(yù)見的。

遇到吞吐量下降時，先判斷瓶頸在哪里：

本機(jī)資源是否緊張。本機(jī)資源主要包括 CPU、內(nèi)存、網(wǎng)絡(luò)帶寬和磁盤吞吐。這些都需要進(jìn)行觀測排查。

依賴服務(wù)是否緊張，如數(shù)據(jù)庫、外部接口是否處理時間過長。

如果這些都無法明顯定位問題所在，那就進(jìn)入程序調(diào)試階段了：在每個請求處理過程中，記錄每一步的時長，找出瓶頸在哪一步，這個粒度會很細(xì)，會要反復(fù)修改日志，反復(fù)運(yùn)行，反復(fù)觀察，但一定會找到問題。

不要一遇到問題就做沒有根據(jù)的胡亂猜測，這時候“發(fā)散思維”幫不上忙，要做的是對問題順藤摸瓜，嚴(yán)謹(jǐn)分析。