系統重構有一段時間了，也陸陸續續的做了資料遷移，業務遷移，作為整個系統的底層服務以及未來整個部門的中颱系統，服務的可用性，穩定性以及效能都至關重要，因此最近在大促之前做了一次核心服務的壓測。
當然壓測生產前必須有乙個除錯的過程，所以會在測試環境進行壓測除錯，下面就是對這次壓測除錯的乙個分析和總結。由於個人對效能調優也是新手，經驗不到，所以如果有不當之處希望有網友指出，不勝感激。
問題發現
首先是先對系統做個壓測，壓出系統的瓶頸。經過摸索，使用jmeter工具完成了初步壓測工作，並得出了以下的結論：
壓測時發現系統的瓶頸在於cpu，壓測cpu達到了98%
問題發現了，那麼接下來就是分析了，為啥瓶頸在cpu，以及如何優化？
發現過程
測試環境使用jmeter進行介面壓測，然後逐步調大併發度，觀察系統吞吐量，然後在ares平台(類似skywalking)上監測jvm記憶體，cpu，執行緒狀態等
然後發現，gc資訊和記憶體資訊很穩定，但是cpu會達到90%，這時檢視jvm的執行緒狀態，發現又70%左右的執行緒處於waiting或者timed_waiting狀態；
初步推算會不會是執行緒過多導致cpu過高？
問題分析
場景首先分析介面的執行流程以及執行緒池的使用場景
簡單描述
客戶端發來乙個請求，由容器執行緒接收，然後通過common執行緒池建立多個執行緒去併發執行，然後通過latch進行等待，等所有的common執行緒執行完在合併然後返回給客戶端；每乙個common執行緒是乙個小任務可以稱為「單品查傭」，common執行緒會首先使用select執行緒池建立4個並行任務進行引數轉換，並且通過latch進行等待然後合併，緊接著繼續併發進行查詢，此時也是使用select執行緒池先去併發查詢然後再common執行緒裡面合併計算結果。
上圖顏色相同的表示在同乙個執行緒或者執行緒池，通過上圖可以大概得出common執行緒池和select執行緒池執行緒個數比為1:5(是不是真的這麼去設定執行緒池大小呢？)。
開始壓測
壓測環境和結果
說明：由於之前做過一次優化，基本將db和es的壓力因素去除了，jvm中的記憶體，頻寬因素基本也排除了，目的就是為了看cpu壓力。
環境：首先根據業務場景，分析由於整個流程中有多次的rpc呼叫或者redis等資料請求所以初步將任務定義為io等待型，目標機器配置2c4g * 2
工具：jmeter
壓測結果：
結果分析
不同執行緒池配置場景下壓測表現
配置(5,25)
在common，select執行緒數分別為5,25時(第一組資料)，隨著併發數的上公升cpu並沒有徒增，穩定在80%左右，但是tps並沒有線性增長，平均響應時間也明顯下降了不少，但是發現併發數的提高沒有將cpu壓到極限，開始懷疑是業務執行緒相關了。
這個時候通過ares平台分析jvm執行緒狀態，發現如下：
然後檢視等待狀態的執行緒，發現大部分是select的執行緒，而且大部分處於gettask方法上面，熟悉執行緒池執行原理的同學都知道，這個是在獲取任務，因為沒有任務了所以阻塞等待了，所以可以指定select的執行緒個數明顯設定過多。從另一方面也說明，common和select的執行緒個數比不對，不是按照分析1:5 設定。因此下面的測試降低select的執行緒數。
配置(5,10)
common和select執行緒數分別為5,10時，減少了select執行緒的個數，cpu和tps和剛剛差不多，但是select的等待執行緒少了，這裡慢慢發現common執行緒個數對tps和cpu有一定的影響，而select執行緒個數影響不大。這時發現增大併發數並不會顯著提高tps，但是響應時間是會明顯增加。
配置(10,10)
common和select執行緒數分別為10,10時，大部分common執行緒在latch上面等待，會不會是select執行緒不夠用？隨著併發數增多，響應時間在下降，但是tps並沒有增加，具體可以看下圖，common在latch上面(和**對應)。
配置(10,20)
common和select執行緒數分別為10,20時，通過觀察執行緒狀態，select執行緒出現等待gettask，cpu會到達94%，tps相應的也會增加，併發數的增加也只是提高了tps，但是會導致響應時間的下降；另外併發增大時，select執行緒都在執行任務，common執行緒出現在latch上面等待，但是響應時間慢了，cpu忙了，因為所有的select執行緒都在執行，執行緒上下文切換(cs)次數肯定會大量增加(可以vmstat檢視)
初步總結
總結： 綜合這4組壓測資料，初步有個簡單的結論，common執行緒池決定了整體的吞吐量(tps)，但是吞吐量提公升的的同時，cpu和響應時間也會增大，而select執行緒需要依賴common執行緒的個數，比例在1.5-2之間，少了會導致tps上不去響應時間也會增加，大了cpu上去了，最終也會導致響應時間的增加，所以common和select執行緒數的選擇需要有據可詢。那麼針對當前的機器配置，兼顧tps，響應時間和cpu使用率(低於90%)，common線核心程池數設定8，select執行緒數設為12，此時100的併發數，cpu最高在90%，tps在760，平均響應時間100ms。
優化方向：通過執行緒狀態和業務流程的分析，我們發現可以將併發部分的業務流程進行細分，主要劃分為io等待型任務和cpu計算型任務，然後使用不同的執行緒池，io型的就多設定執行緒數，cpu型的就少一點。有個初始經驗值
io 型：2 * cpu個數
cpu型：cpu個數 + 1
附壓測時機器的其他指標，供參考
關於找一找教程網
[一次介面壓測除錯]
記錄一次壓測問題
同一套程式，之前放在伺服器上使用，公司內部壓測和發布給客戶使用，均未出現問題。後由於客戶業務需求，將其移植到嵌入式平台。公司內部壓測過程中，出現三種異常。問題1 大併發壓測，服務程序被killed掉。問題2 大併發壓測，服務掛掉，最後的列印為底層的錯誤日誌。問題3 大併發壓測，服務掛掉，列印另外的底...
將壓測的結果儲存 記一次效能壓測
接到乙個需求 乙個應用的效能壓測，在水平擴容後，tps並沒有增加。希望排查下具體問題。症狀表現如下 應用機器為1c1g，k8s負責管理。測試同學在做效能壓測時，發現 4副本和10副本的集群總tps變化不大。首先對壓測方案進行了重新設計 機型先調整為4c8g。單副本壓測，看瓶頸。調整機型，再壓基線。集...
效能方案 壓測介面選取標準
基礎的使用者服務需要進行線上壓測，但是這個專案的介面數400 目前沒有流量錄製的功能，完成400 個介面的指令碼編寫和資料準備工作量是巨大的 需要從400 介面中挑選部分介面150 進行效能壓測，那如何選擇哪些介面進行壓測呢？如果根據線上請求量top150個介面，但是有些介面比如引數是list格式，...