效能壓測詭異的Requests/second 響應刺尖問題，requestssecond

效能壓測詭異的Requests/second 響應刺尖問題，requestssecond

最近一段時間都在忙著轉java項目最後的衝刺，前期的coding翻代碼、debug、fixbug都逐漸收尾，進入上線前的效能壓測。

雖然不是大促前的效能壓測要求，但是為了安全起見，需要摸個底心裡有個數。

畢竟這次轉java的服務都是集團核心公用服務(主要是訂單網域服務)。（等我們順利上線了，我再來好好總結下其中的坎坷和壯舉。）

廢話不多說了，直接進入主題。

由於這次壓測主要重點是關注正向的兩個核心訂單服務，下單服務、查單服務。查單服務初步壓測下來問題不大，主要是db的索引和cache的問題。

下單服務有兩個核心介面，預訂單查詢、建立訂單。預訂單查詢主要是訂單的前置狀態的結算頁匯總計算（不僅是結算頁），不落具體訂單，如，各種促銷、卡券碼、虛擬幣的規則計算等等。

建立訂單邏輯稍微複雜點，對周邊的系統及中介軟體依賴也比較多，所以需要重點關注，至少心中要有數，哪怕下遊的哪個服務的效能有問題，在下次大促的時候可以最佳化掉。

（並不是說所有效能問題都需要及時最佳化，只要保證能撐得起業務量的一定範圍就好，因為效能最佳化無止境，需要把握好節奏。）

提交橫向壓測前我們需要自己先過一遍，這樣才能加快壓測的效率，由於時間比較緊再加上客觀的環境問題，我將服務中幾個沒有壓測環境的依賴去掉。（有關壓測的一些實踐我將在下篇文章好好總結下，這裡就不展開了。）壓測了幾輪（時間差不多30分鐘左右。），消除了一些環境、代碼、依賴的障礙，提交橫向走壓測流程，接著就去忙其他的事情了。（詭異的問題比較多~_~，mybatis pagehelperplugin好像也有點並發問題，還沒定位到，不知道是用的不對還是什麼情況，繼續排查，有結論了我在總結分享下。）

1.壓測報告：

2.查看伺服器監控情況：

JAVA GC：

3.查看DB情況：

4.分析

上面圖中有一幅圖有點問題，不知道大家看出來了沒有。就是我下單服務的應用伺服器的網路流量有問題，receive、send對不上。

5.排查

其實這個時候有一個結論，就是伺服器其實沒有瓶頸，不管是應用伺服器還是DB、cache。那問題應該是在程式方面。（效能分析由上至下、由下至上集合分析《java效能最佳化權威指南》）。

開始嘗試排查依賴服務，下單服務主要依賴商品、促銷。cache不是問題，因為本地有一級緩衝，而且緩衝的到期時間對不上，壓測環境的redis和MySQL在一台機器上。所以DB沒有問題，基本上redis應該也沒啥問題。（這台機器很強悍）還有部分的依賴業務方的介面我已經注釋掉了，不會有依賴。

開始懷疑商品、促銷，但是我之前分別對這兩個服務進行過壓測，這兩個服務基本上都是命中cache，QPS基本上接近18000。現在也只好對這兩個服務再進行一輪詳細的壓測。

結果很遺憾，沒啥線索，效能很好。

開始排查線程池問題，是否有block線程，通過jstack 列印出線程，基本上都是XNIO的condition wait，也沒有啥不正常。因為下單服務的其他介面都挺正常的，線程池問題應該不大。下單成功之後有意個hold的情境，就是hold虛擬幣、卡券碼等等之類的邏輯，這裡面使用了fiexd線程池（5個，設定了飽和策略及日誌輸出。），問題也不大。

開始排查日誌，restful-slow.log，jdbc-slow.log、錯誤記錄檔等等，一頓cat… grep…wc –l，啥也沒有異常。(shit開始冒汗了。。。)

只能上大招了，開始嘗試注代碼，然後壓測，逐個嘗試，先注釋DB、然後線程池hold邏輯、然後發送訊息。(無賴之舉。。。)

6.浮出水面

等我嘗試注釋掉發送訊息的邏輯時候發現問題不出現了，有希望了。開始進去看代碼，沒啥邏輯，走的是spring 的RabbitTemplate.convertAndSend 方法。（這是個同步方法，沒有任何聲明說他是async的。）

/**發送訊息*/
template.convertAndSend(messageConfig.getExchangeName(), routingKey, message, amqpMessage -> {

翻了下資料，沒啥特殊的使用要求。

順便看了下設定檔，發送訊息走的是qa環境，這個我知道，因為當時壓測環境的rabbitmq一時還沒好，而且我們走的是先定義再使用queue的流程，所以如果要用我需要先上去配置好才能使用。當時圖省事就先用了，自己壓測下來也沒啥問題，畢竟MQ的設計輸送量都很高的，TPS足夠我們用的，再加上我之前也壓過qa的MQ沒啥問題。

（資源沒隔離是因為一些客觀原因，有時候壓測環境是臨時搭建的。用到qa環境的中介軟體還有codis，但是codis基本是二級緩衝，所以問題不大，先過。(回頭沒轍再來找它。)

搞來了qa環境的rabbitmq伺服器帳號，同時開啟rabbtimq管理介面中的dashboard。開始重點關注這台伺服器。(top命名開啟，P\M看下rabbitmq各項指標。)

7.打臉

等我在開會的時候，壓測兄弟找我，哥哥那個問題又出現了。

8.總結

能隔離環境的盡量隔離，排查環境問題最頭疼，但是有時候又無法避免。（下篇壓測文章分享下，環境問題的排查方式和工具）

遇到問題一定要搞清楚根源，就算找不到根源也知道把它限定在某個範圍內，比如限制到DB、作業系統等等。

 

作者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文著作權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文串連，否則保留追究法律責任的權利。