接到乙個需求：乙個應用的效能壓測，在水平擴容後，tps並沒有增加。希望排查下具體問題。
症狀表現如下：
應用機器為1c1g，k8s負責管理。測試同學在做效能壓測時，發現 4副本和10副本的集群總tps變化不大。
首先對壓測方案進行了重新設計：
機型先調整為4c8g。
單副本壓測，看瓶頸。
調整機型，再壓基線。
集群壓測。
資料如下：
單程序、單副本： rt 111ms， tps 9，cpu占用 2.7c，記憶體 200m。
雙程序、單副本： rt 117ms， tps 16，cpu占用4.2c，記憶體300m。
5程序、單副本：rt 169ms，tps 27，cpu占用5.03c，記憶體777m。
10程序、單副本：rt 600ms，tps 15， cpu占用2.76c，記憶體885m。
6程序、單副本：rt 190ms，tps 27，cpu占用5.2c，記憶體910m。
初步分析如下：
因為k8s中設定了動態cpu調整，超出4c時，會動態分配空閒的cpu，所以cpu超出實際要求部分是正常的。記憶體看起來不是瓶頸，cpu是瓶頸，符合演算法服務應用的特性。在10程序的壓測結果中，cpu占用下降，tps 下降，rt上公升較多，看起來壓力沒有傳導到實際的應用副本上。從3和5的測試來看，已經是單副本當前效能的極限。所以做以下調整，機型調整為8c8g。
資料如下：
6程序：rt 198ms tps 30 cpu占用5.3c，記憶體 819m。
10程序：rt 297ms tps 33.5 cpu占用5.4c，記憶體846m。
從結果看，10程序對比6進行沒有線性增長。cpu的公升配也沒有帶來效能的進一步提公升。做出以下調整：將單副本的執行緒數由10調整為20。
資料如下：
6程序： rt 192ms tps 31.8 cpu占用5.2c，記憶體887m。
可見執行緒的增加並沒有帶來顯著的提公升，應用本身的執行緒機制也有問題。記憶體基本無影響，後續不在關注。機型調整為5c2g，單副本的執行緒數仍改回10。
資料如下：
6程序、單副本：rt 197ms tps 30 cpu占用5.1c
6程序、雙副本：rt 132ms tps 43.6 cpu占用 <4.5c
12程序、雙副本：rt 203ms tps 60 cpu占用 5c 左右。
60程序、10副本：rt 350ms tps 172 cpu占用 2c 左右。
從結果可見4中，效能明顯下降，猜測可能是網路頻寬問題。但是排查了k8s中 ingress (負載均衡)的資料，頻寬並沒有被打滿，而且連線數基本等於壓測程序數。開始懷疑是副本所在宿主機的問題。
排查10個副本所在宿主機，發現有4個副本被分配到了兩台宿主機(阿里雲ecs)上。於是將副本改為8個，保證每個副本都在不同的宿主機上，用之前壓測建立的單副本6程序的基線，進行48程序的壓測。我們發現 tps 仍未達到 30 * 8 =240的預期，只有170左右。排查8個副本cpu，發現有數個副本的cpu占用沒有到達5c。進一步檢視宿主機資料，發現沒有達到5c的副本所在的宿主機cpu基本已到了90%以上，基本確定是k8s中cpu超賣導致。
將副本的cpu占用改為獨佔後，根據實際測試集群空閒cpu的數量，改為 7個副本，壓測結果為 rt 200ms , tps 220 ， cpu占用 基本5c左右。該結果符合我們的預期，確定是cpu超賣導致的壓測效能下降，後續進入到應用的效能調優階段。
記錄一次壓測問題
同一套程式，之前放在伺服器上使用，公司內部壓測和發布給客戶使用，均未出現問題。後由於客戶業務需求，將其移植到嵌入式平台。公司內部壓測過程中，出現三種異常。問題1 大併發壓測，服務程序被killed掉。問題2 大併發壓測，服務掛掉，最後的列印為底層的錯誤日誌。問題3 大併發壓測，服務掛掉，列印另外的底...
壓測介面執行緒數設定 一次介面壓測除錯
系統重構有一段時間了，也陸陸續續的做了資料遷移，業務遷移，作為整個系統的底層服務以及未來整個部門的中颱系統，服務的可用性，穩定性以及效能都至關重要，因此最近在大促之前做了一次核心服務的壓測。當然壓測生產前必須有乙個除錯的過程，所以會在測試環境進行壓測除錯，下面就是對這次壓測除錯的乙個分析和總結。由於...
一次web專案首頁壓測記錄（未完）
公司運營的人員說公司之前的外包web專案每天早上首頁都打不開，領導讓我對首頁做併發壓測，沒有任何業務場景需求給出，只能自己摸索，使用工具是jmeter，首先從50併發開始模擬，50併發的結果如下 是不是很爛，平均響應時間都到了27秒，當時覺得這伺服器真爛，後面分析了一下 其實是問了之前老大肖工，感謝...