本博客轉發自：老張https://www.cnblogs.com/imyalost/p/10850811.html
一、注意事項
1、斷言
在壓測時，為了判斷發送的請求是否成功，一般會通過對請求添加斷言來實現。使用斷言時，建議遵循如下規范：
①、斷言內容盡量以status/code、msg/message來判斷（當然前提是接口設計遵循Restful規范）
Jmeter示例：
阿里雲PTS：
如果使用的是PTS壓測，則斷言設置中，以code/status、msg/message等於對應的值為准；
②、盡可能不要將所有的Response Body內容作為斷言判斷的內容，這樣很可能會導致大量的“斷言”失敗；
PS：然后很遺憾的是，見過很多做壓測的童鞋，斷言內容以整個響應參數內容做斷言，導致大量的報錯。
2、成功率
一般在性能測試中，我們都追求99.99%的成功率，但在實際的測試過程中，為了盡可能覆蓋代碼邏輯，在准備階段會盡可能的准備較多的熱點數據去做到覆蓋。
這樣的話，我們所關注的成功率指標，就要分為如下兩種：
①、事務成功率
事務成功率在某些時候也可以視為請求成功率，在斷言判斷時以code/status等內容來作為請求是否成功的衡量依據；
②、業務成功率
實際的業務場景中，所謂的成功率，並不能僅根據返回的code/status來判斷。比如：一個查詢請求，無論是返回正確的查詢結果還是由於對應數據返回空，這個請求都是成功的。
對應的響應參數可能是： {"status":"200","message":"success"} ；也可能是： {"status":"200","message":"暫無對應結果"} 。
PS：在性能測試過程中，考慮到業務成功率和請求成功率的不同指標，結合斷言內容，需要靈活設置斷言的方式（當然，我依然建議遵循如上的2點斷言規范）！
二、常見性能瓶頸解析及調優方案
在性能測試中，導致性能出現瓶頸的原因很多，但通過直觀的監控圖表現出來的樣子，根據出現的頻次，大概有如下幾種：
| 性能瓶頸出現頻次 | 具體表現 |
| 高 | TPS波動較大 |
| 高 | 高並發下大量報錯 |
| 中 | 集群類系統，各服務節點負載不均衡 |
| 中 | 並發數不斷增加，TPS上不去，CPU耗用不高 |
| 低 | 壓測過程中TPS不斷下降，CPU使用率不斷降低 |
下面對常見的幾種性能瓶頸原因進行解析，並說說常見的一些調優方案：
1、TPS波動較大
原因解析：出現TPS波動較大問題的原因一般有網絡波動、其他服務資源競爭以及垃圾回收問題這三種。
性能測試環境一般都是在內網或者壓測機和服務在同一網段，可通過監控網絡的出入流量來排查；
其他服務資源競爭也可能造成這一問題，可以通過Top命令或服務梳理方式來排查在壓測時是否有其他服務運行導致資源競爭；
垃圾回收問題相對來說是最常見的導致TPS波動的一種原因，可以通過GC監控命令來排查，命令如下：
1 # 實時打印到屏幕 2 jstat -gc PID 300 10 3 jstat -gcutil PID 300 10 4 # GC信息輸出到文件 5 jstat -gc PID 1000 120 >>/path/gc.txt 6 jstat -gcutil PID 1000 120 >>/path/gc.txt
調優方案：
網絡波動問題，可以讓運維同事協助解決（比如切換網段或選擇內網壓測），或者等到網絡較為穩定時候進行壓測驗證；
資源競爭問題：通過命令監控和服務梳理，找出壓測時正在運行的其他服務，通過溝通協調停止該服務（或者換個沒資源競爭的服務節點重新壓測也可以）；
垃圾回收問題：通過GC文件分析，如果發現有頻繁的FGC，可以通過修改JVM的堆內存參數Xmx，然后再次壓測驗證（Xmx最大值不要超過服務節點內存的50%！）
2、高並發下大量報錯
原因解析：出現該類問題，常見的原因有短連接導致的端口被完全占用以及線程池最大線程數配置較小及超時時間較短導致。
調優方案：
短連接問題：修改服務節點的tcp_tw_reuse參數為1，釋放TIME_WAIT scoket用於新的連接；
線程池問題：修改服務節點中容器的server.xml文件中的配置參數，主要修改如下幾個參數：
# 最大線程數，即服務端可以同時響應處理的最大請求數 maxThreads="200" # Tomcat的最大連接線程數，即超過設定的閾值，Tomcat會關閉不再需要的socket線程 maxSpareThreads="200" # 所有可用線程耗盡時，可放在請求等待隊列中的請求數，超過該閾值的請求將不予處理，返回Connection refused錯誤 acceptCount="200" # 等待超時的閾值，單位為毫秒，設置為0時表示永不超時 connectionTimeout="20000"
3、集群類系統，各服務節點負載不均衡
原因解析：出現這類問題的原因一般是SLB服務設置了會話保持，會導致請求只分發到其中一個節點。
調優方案：如果確認是如上原因，可通過修改SLB服務（F5/HA/Nginx）的會話保持參數為None，然后再次壓測驗證；
4、並發數不斷增加，TPS上不去，CPU使用率較低
原因解析：出現該類問題，常見的原因有：SQL沒有創建索引/SQL語句篩選條件不明確、代碼中設有同步鎖，高並發時出現鎖等待；
調優方案：
SQL問題：沒有索引就創建索引，SQL語句篩選條件不明確就優化SQL和業務邏輯；
同步鎖問題：是否去掉同步鎖，有時候不僅僅是技術問題，還涉及到業務邏輯的各種判斷，是否去掉同步鎖，建議和開發產品同事溝通確認；
5、壓測過程中TPS不斷下降，CPU使用率不斷降低
原因解析：一般來說，出現這種問題的原因是因為線程block導致，當然不排除其他可能；
調優方案：如果是線程阻塞問題，修改線程策略，然后重新驗證即可；
6、其他
除了上述的五種常見性能瓶頸，還有其他，比如：connection reset、服務重啟、timeout等，當然，分析定位后，你會發現，我們常見的性能瓶頸，
導致其的原因大多都是因為參數配置、服務策略、阻塞及各種鎖導致。。。
性能瓶頸分析參考准則：從上至下、從局部到整體