明確問題
首先我們要確認(rèn)是哪些性能指標(biāo)不達(dá)到要求，或者需要改進(jìn)<br />
常見的性能指標(biāo)：
用戶體驗層面
- 用戶響應(yīng)時間
就是用戶感受軟件系統(tǒng)為其服務(wù)所消耗的時間。對于web系統(tǒng)，請求的相應(yīng)時間指的是從客戶端發(fā)起的一個請求時間，到客戶端接收到從服務(wù)器返回的相應(yīng)結(jié)束。在互聯(lián)網(wǎng)上對于用戶響應(yīng)時間，有一個普遍的標(biāo)準(zhǔn)：2/5/10秒原則。
也就是說，在2秒之內(nèi)給客戶響應(yīng)被用戶認(rèn)為是“非常有吸引力”的用戶體驗。在5秒之內(nèi)響應(yīng)客戶被認(rèn)為“比較不錯”的用戶體驗，在10秒內(nèi)給用戶響應(yīng)被認(rèn)為“糟糕”的用戶體驗。如果超過10秒還沒有得到響應(yīng)，那么大多用戶會認(rèn)為這次請求是失敗的。
事務(wù)處理層面
- 每秒處理事務(wù)（TPS）
-
事務(wù)平均響應(yīng)時間（RT）
- 90%響應(yīng)時間
- 并發(fā)用戶數(shù)
- HTTP錯誤率
這里有個簡單的關(guān)聯(lián)關(guān)系：并發(fā)用戶數(shù)/TPS/RT之間的關(guān)系
假如并發(fā)數(shù)為10，接口RT為500ms，那每秒鐘通過的請求數(shù)（TPS）應(yīng)該為10（1000ms/500ms）= 20<br />此處僅為簡單換算，如果數(shù)據(jù)出入較大，需要進(jìn)一步分析。
*另外最優(yōu)并發(fā)和最大并發(fā)之間的關(guān)系，在上一篇已經(jīng)講過了，可以參考這篇文章https://www.cnblogs.com/jackei/archive/2006/11/20/565527.html
服務(wù)器資源層面
- CPU使用情況
- 內(nèi)存使用情況和持續(xù)表現(xiàn)
- 磁盤IO速度
- 上行/下行網(wǎng)速情況
排查原則
為了能快速的排查分析，我們建議排查順序為：從表及里，從易到難。<br />按照下面這個圖的話，建議由左到右，由上到下
image.png
可能會出現(xiàn)瓶頸的地方
硬件瓶頸：
一般指的是CPU、內(nèi)存、磁盤I/O 方面的問題，分為服務(wù)器硬件瓶頸、網(wǎng)絡(luò)瓶頸
中間件性能瓶頸：
web軟件，數(shù)據(jù)庫，緩存等
應(yīng)用程序瓶頸：
JVM參數(shù)不合理，容器配置不合理，慢SQL，慢事務(wù)，數(shù)據(jù)庫設(shè)計不合理，程序架構(gòu)規(guī)劃不合理，程序本身設(shè)計有問題（串行處理、請求的處理線程不夠、無緩沖、無緩存、生產(chǎn)者和消費者不協(xié)調(diào)等），造成系統(tǒng)在大量用戶方位時性能低下而造成的瓶頸。
操作系統(tǒng)瓶頸：
連接數(shù)，虛擬內(nèi)存，內(nèi)核參數(shù)等
網(wǎng)絡(luò)設(shè)備瓶頸：
包括但不限于SLB/WAF/高防IP/CDN/全站加速等
幾種常見的瓶頸
1、TPS波動較大
原因解析：出現(xiàn)TPS波動較大問題的原因一般有網(wǎng)絡(luò)波動、其他服務(wù)資源競爭以及垃圾回收問題這三種。
- 性能測試環(huán)境一般都是在內(nèi)網(wǎng)或者壓測機(jī)和服務(wù)在同一網(wǎng)段，可通過監(jiān)控網(wǎng)絡(luò)的出入流量來排查；
- 其他服務(wù)資源競爭也可能造成這一問題，可以通過Top命令或服務(wù)梳理方式來排查在壓測時是否有其他服務(wù)運(yùn)行導(dǎo)致資源競爭；
- 垃圾回收問題相對來說是最常見的導(dǎo)致TPS波動的一種原因，可以通過GC監(jiān)控命令來排查，命令如下：
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
調(diào)優(yōu)方案：
- 網(wǎng)絡(luò)波動問題，可以讓運(yùn)維同事協(xié)助解決（比如切換網(wǎng)段或選擇內(nèi)網(wǎng)壓測），或者等到網(wǎng)絡(luò)較為穩(wěn)定時候進(jìn)行壓測驗證；
- 資源競爭問題：通過命令監(jiān)控和服務(wù)梳理，找出壓測時正在運(yùn)行的其他服務(wù)，通過溝通協(xié)調(diào)停止該服務(wù)（或者換個沒資源競爭的服務(wù)節(jié)點重新壓測也可以）；
- 垃圾回收問題：通過GC文件分析，如果發(fā)現(xiàn)有頻繁的FGC，可以通過修改JVM的堆內(nèi)存參數(shù)Xmx，然后再次壓測驗證（Xmx最大值不要超過服務(wù)節(jié)點內(nèi)存的50%！）
2、高并發(fā)下大量報錯
原因解析：出現(xiàn)該類問題，常見的原因有短連接導(dǎo)致的端口被完全占用以及線程池最大線程數(shù)配置較小及超時時間較短導(dǎo)致。
調(diào)優(yōu)方案：
- 短連接問題：修改服務(wù)節(jié)點的tcp_tw_reuse參數(shù)為1，釋放TIME_WAIT scoket用于新的連接；
- 線程池問題：修改服務(wù)節(jié)點中容器的server.xml文件中的配置參數(shù)，主要修改如下幾個參數(shù)：
# 最大線程數(shù)，即服務(wù)端可以同時響應(yīng)處理的最大請求數(shù)
maxThreads="200"
# Tomcat的最大連接線程數(shù)，即超過設(shè)定的閾值，Tomcat會關(guān)閉不再需要的socket線程
maxSpareThreads="200"
# 所有可用線程耗盡時，可放在請求等待隊列中的請求數(shù)，超過該閾值的請求將不予處理，返回Connection refused錯誤
acceptCount="200"
# 等待超時的閾值，單位為毫秒，設(shè)置為0時表示永不超時
connectionTimeout="20000"
<a name="mDKIK"></a>
3、集群類系統(tǒng)，各服務(wù)節(jié)點負(fù)載不均衡
原因解析：出現(xiàn)這類問題的原因一般是SLB服務(wù)設(shè)置了會話保持，會導(dǎo)致請求只分發(fā)到其中一個節(jié)點。<br />調(diào)優(yōu)方案：如果確認(rèn)是如上原因，可通過修改SLB服務(wù)（F5/HA/Nginx）的會話保持參數(shù)為None，然后再次壓測驗證；
4、并發(fā)數(shù)不斷增加，TPS上不去，CPU使用率較低
原因解析：出現(xiàn)該類問題，常見的原因有：SQL沒有創(chuàng)建索引/SQL語句篩選條件不明確、代碼中設(shè)有同步鎖，高并發(fā)時出現(xiàn)鎖等待；
調(diào)優(yōu)方案：
- SQL問題：沒有索引就創(chuàng)建索引，SQL語句篩選條件不明確就優(yōu)化SQL和業(yè)務(wù)邏輯；
- 同步鎖問題：是否去掉同步鎖，有時候不僅僅是技術(shù)問題，還涉及到業(yè)務(wù)邏輯的各種判斷，是否去掉同步鎖，建議和開發(fā)產(chǎn)品同事溝通確認(rèn)；
5、壓測過程中TPS不斷下降，CPU使用率不斷降低
原因解析：一般來說，出現(xiàn)這種問題的原因是因為線程block導(dǎo)致，當(dāng)然不排除其他可能；
調(diào)優(yōu)方案：如果是線程阻塞問題，修改線程策略，然后重新驗證即可；
6、其他
除了上述的五種常見性能瓶頸，還有其他，比如：connection reset、服務(wù)重啟、timeout等，當(dāng)然，分析定位后，你會發(fā)現(xiàn)，我們常見的性能瓶頸，導(dǎo)致其的原因大多都是因為參數(shù)配置、服務(wù)策略、阻塞及各種鎖導(dǎo)致。。。
參考文章：
https://blog.csdn.net/weixin_43820813/article/details/109715497
https://www.cnblogs.com/aresxin/p/p63464523.html
https://www.cnblogs.com/Mr-xiao/p/6992948.html
https://www.cnblogs.com/imyalost/p/10850811.html
關(guān)于性能測試，安利下蟲師的博客，各種內(nèi)容非常詳細(xì)。
https://www.cnblogs.com/fnng/
