---

前言

常見(jiàn)的一些性能缺陷表現(xiàn)及如何進(jìn)行定位分析并且調(diào)優(yōu)。

注意事項(xiàng)

1、斷言
在壓測(cè)時(shí)，為了判斷發(fā)送的請(qǐng)求是否成功，一般會(huì)通過(guò)對(duì)請(qǐng)求添加斷言來(lái)實(shí)現(xiàn)。使用斷言時(shí)，建議遵循如下規(guī)范：

①斷言?xún)?nèi)容盡量以status/code、msg/message來(lái)判斷（當(dāng)然前提是接口設(shè)計(jì)遵循Restful規(guī)范）

Jmeter示例：

阿里云PTS：

如果使用的是PTS壓測(cè)，則斷言設(shè)置中，以code/status、msg/message等于對(duì)應(yīng)的值為準(zhǔn)；

②盡可能不要將所有的Response Body內(nèi)容作為斷言判斷的內(nèi)容，這樣很可能會(huì)導(dǎo)致大量的“斷言”失敗；

PS：然后很遺憾的是，見(jiàn)過(guò)很多做壓測(cè)的童鞋，斷言?xún)?nèi)容以整個(gè)響應(yīng)參數(shù)內(nèi)容做斷言，導(dǎo)致大量的報(bào)錯(cuò)。

2、成功率
一般在性能測(cè)試中，我們都追求99.99%的成功率，但在實(shí)際的測(cè)試過(guò)程中，為了盡可能覆蓋代碼邏輯，在準(zhǔn)備階段會(huì)盡可能的準(zhǔn)備較多的熱點(diǎn)數(shù)據(jù)去做到覆蓋。

這樣的話(huà)，我們所關(guān)注的成功率指標(biāo)，就要分為如下兩種：

①事務(wù)成功率
事務(wù)成功率在某些時(shí)候也可以視為請(qǐng)求成功率，在斷言判斷時(shí)以code/status等內(nèi)容來(lái)作為請(qǐng)求是否成功的衡量依據(jù)；

②業(yè)務(wù)成功率
實(shí)際的業(yè)務(wù)場(chǎng)景中，所謂的成功率，并不能僅根據(jù)返回的code/status來(lái)判斷。比如：一個(gè)查詢(xún)請(qǐng)求，無(wú)論是返回正確的查詢(xún)結(jié)果還是由于對(duì)應(yīng)數(shù)據(jù)返回空，這個(gè)請(qǐng)求都是成功的。

對(duì)應(yīng)的響應(yīng)參數(shù)可能是： {“status”:“200”,“message”:“success”} ；也可能是： {“status”:“200”,“message”:“暫無(wú)對(duì)應(yīng)結(jié)果”} 。

PS：在性能測(cè)試過(guò)程中，考慮到業(yè)務(wù)成功率和請(qǐng)求成功率的不同指標(biāo)，結(jié)合斷言?xún)?nèi)容，需要靈活設(shè)置斷言的方式（當(dāng)然，我依然建議遵循如上的2點(diǎn)斷言規(guī)范）

常見(jiàn)性能瓶頸解析及調(diào)優(yōu)方案

在性能測(cè)試中，導(dǎo)致性能出現(xiàn)瓶頸的原因很多，但通過(guò)直觀的監(jiān)控圖表現(xiàn)出來(lái)的樣子，根據(jù)出現(xiàn)的頻次，大概有如下幾種：

性能瓶頸出現(xiàn)頻次	具體表現(xiàn)
高	TPS波動(dòng)較大
高	高并發(fā)下大量報(bào)錯(cuò)
中	集群類(lèi)系統(tǒng)，各服務(wù)節(jié)點(diǎn)負(fù)載不均衡
中	并發(fā)數(shù)不斷增加，TPS上不去，CPU耗用不高
低	壓測(cè)過(guò)程中TPS不斷下降，CPU使用率不斷降低
下面對(duì)常見(jiàn)的幾種性能瓶頸原因進(jìn)行解析，并說(shuō)說(shuō)常見(jiàn)的一些調(diào)優(yōu)方案：

1、TPS波動(dòng)較大
原因解析：出現(xiàn)TPS波動(dòng)較大問(wèn)題的原因一般有網(wǎng)絡(luò)波動(dòng)、其他服務(wù)資源競(jìng)爭(zhēng)以及垃圾回收問(wèn)題這三種。

性能測(cè)試環(huán)境一般都是在內(nèi)網(wǎng)或者壓測(cè)機(jī)和服務(wù)在同一網(wǎng)段，可通過(guò)監(jiān)控網(wǎng)絡(luò)的出入流量來(lái)排查；

其他服務(wù)資源競(jìng)爭(zhēng)也可能造成這一問(wèn)題，可以通過(guò)Top命令或服務(wù)梳理方式來(lái)排查在壓測(cè)時(shí)是否有其他服務(wù)運(yùn)行導(dǎo)致資源競(jìng)爭(zhēng)；

垃圾回收問(wèn)題相對(duì)來(lái)說(shuō)是最常見(jiàn)的導(dǎo)致TPS波動(dòng)的一種原因，可以通過(guò)GC監(jiān)控命令來(lái)排查，命令如下：

 # 實(shí)時(shí)打印到屏幕
jstat -gc PID 300 10
jstat -gcutil PID 300 10# GC信息輸出到文件
jstat -gc PID 1000 120 >>/path/gc.txt
jstat -gcutil PID 1000 120 >>/path/gc.txt

調(diào)優(yōu)方案：
網(wǎng)絡(luò)波動(dòng)問(wèn)題，可以讓運(yùn)維同事協(xié)助解決（比如切換網(wǎng)段或選擇內(nèi)網(wǎng)壓測(cè)），或者等到網(wǎng)絡(luò)較為穩(wěn)定時(shí)候進(jìn)行壓測(cè)驗(yàn)證；

資源競(jìng)爭(zhēng)問(wèn)題：通過(guò)命令監(jiān)控和服務(wù)梳理，找出壓測(cè)時(shí)正在運(yùn)行的其他服務(wù)，通過(guò)溝通協(xié)調(diào)停止該服務(wù)（或者換個(gè)沒(méi)資源競(jìng)爭(zhēng)的服務(wù)節(jié)點(diǎn)重新壓測(cè)也可以）；

垃圾回收問(wèn)題：通過(guò)GC文件分析，如果發(fā)現(xiàn)有頻繁的FGC，可以通過(guò)修改JVM的堆內(nèi)存參數(shù)Xmx，然后再次壓測(cè)驗(yàn)證（Xmx最大值不要超過(guò)服務(wù)節(jié)點(diǎn)內(nèi)存的50%！）

2、高并發(fā)下大量報(bào)錯(cuò)
原因解析：出現(xiàn)該類(lèi)問(wèn)題，常見(jiàn)的原因有短連接導(dǎo)致的端口被完全占用以及線(xiàn)程池最大線(xiàn)程數(shù)配置較小及超時(shí)時(shí)間較短導(dǎo)致。

調(diào)優(yōu)方案：
短連接問(wèn)題：修改服務(wù)節(jié)點(diǎn)的tcp_tw_reuse參數(shù)為1，釋放TIME_WAIT scoket用于新的連接；

線(xiàn)程池問(wèn)題：修改服務(wù)節(jié)點(diǎn)中容器的server.xml文件中的配置參數(shù)，主要修改如下幾個(gè)參數(shù)：

# 最大線(xiàn)程數(shù)，即服務(wù)端可以同時(shí)響應(yīng)處理的最大請(qǐng)求數(shù)
maxThreads="200"                        
# Tomcat的最大連接線(xiàn)程數(shù)，即超過(guò)設(shè)定的閾值，Tomcat會(huì)關(guān)閉不再需要的socket線(xiàn)程       
maxSpareThreads="200"               
# 所有可用線(xiàn)程耗盡時(shí)，可放在請(qǐng)求等待隊(duì)列中的請(qǐng)求數(shù)，超過(guò)該閾值的請(qǐng)求將不予處理，返回Connection refused錯(cuò)誤
acceptCount="200"                 
# 等待超時(shí)的閾值，單位為毫秒，設(shè)置為0時(shí)表示永不超時(shí)
connectionTimeout="20000"# 最大線(xiàn)程數(shù)，即服務(wù)端可以同時(shí)響應(yīng)處理的最大請(qǐng)求數(shù)
maxThreads="200"                        
# Tomcat的最大連接線(xiàn)程數(shù)，即超過(guò)設(shè)定的閾值，Tomcat會(huì)關(guān)閉不再需要的socket線(xiàn)程       
maxSpareThreads="200"               
# 所有可用線(xiàn)程耗盡時(shí)，可放在請(qǐng)求等待隊(duì)列中的請(qǐng)求數(shù)，超過(guò)該閾值的請(qǐng)求將不予處理，返回Connection refused錯(cuò)誤
acceptCount="200"                 
# 等待超時(shí)的閾值，單位為毫秒，設(shè)置為0時(shí)表示永不超時(shí)
connectionTimeout="20000"         

3、集群類(lèi)系統(tǒng)，各服務(wù)節(jié)點(diǎn)負(fù)載不均衡
原因解析：出現(xiàn)這類(lèi)問(wèn)題的原因一般是SLB服務(wù)設(shè)置了會(huì)話(huà)保持，會(huì)導(dǎo)致請(qǐng)求只分發(fā)到其中一個(gè)節(jié)點(diǎn)。

調(diào)優(yōu)方案：如果確認(rèn)是如上原因，可通過(guò)修改SLB服務(wù)（F5/HA/Nginx）的會(huì)話(huà)保持參數(shù)為None，然后再次壓測(cè)驗(yàn)證；

4、并發(fā)數(shù)不斷增加，TPS上不去，CPU使用率較低
原因解析：出現(xiàn)該類(lèi)問(wèn)題，常見(jiàn)的原因有：SQL沒(méi)有創(chuàng)建索引/SQL語(yǔ)句篩選條件不明確、代碼中設(shè)有同步鎖，高并發(fā)時(shí)出現(xiàn)鎖等待；

調(diào)優(yōu)方案：
SQL問(wèn)題：沒(méi)有索引就創(chuàng)建索引，SQL語(yǔ)句篩選條件不明確就優(yōu)化SQL和業(yè)務(wù)邏輯；

同步鎖問(wèn)題：是否去掉同步鎖，有時(shí)候不僅僅是技術(shù)問(wèn)題，還涉及到業(yè)務(wù)邏輯的各種判斷，是否去掉同步鎖，建議和開(kāi)發(fā)產(chǎn)品同事溝通確認(rèn)；

5、壓測(cè)過(guò)程中TPS不斷下降，CPU使用率不斷降低
原因解析：一般來(lái)說(shuō)，出現(xiàn)這種問(wèn)題的原因是因?yàn)榫€(xiàn)程block導(dǎo)致，當(dāng)然不排除其他可能；

調(diào)優(yōu)方案：如果是線(xiàn)程阻塞問(wèn)題，修改線(xiàn)程策略，然后重新驗(yàn)證即可；

除了上述的5種常見(jiàn)性能瓶頸，還有其他，比如：connection reset、服務(wù)重啟、timeout等，當(dāng)然，分析定位后，你會(huì)發(fā)現(xiàn)，我們常見(jiàn)的性能瓶頸，

導(dǎo)致其的原因大多都是因?yàn)閰?shù)配置、服務(wù)策略、阻塞及各種鎖導(dǎo)致的。

下面是我整理的2023年最全的軟件測(cè)試工程師學(xué)習(xí)知識(shí)架構(gòu)體系圖

一、Python編程入門(mén)到精通

二、接口自動(dòng)化項(xiàng)目實(shí)戰(zhàn)

三、Web自動(dòng)化項(xiàng)目實(shí)戰(zhàn)

四、App自動(dòng)化項(xiàng)目實(shí)戰(zhàn)

五、一線(xiàn)大廠簡(jiǎn)歷

六、測(cè)試開(kāi)發(fā)DevOps體系

七、常用自動(dòng)化測(cè)試工具

八、JMeter性能測(cè)試

九、總結(jié)（尾部小驚喜）

在逆境中汲取力量，在困難中錘煉意志，努力奮斗，方能超越自我。不管前路多坎坷，堅(jiān)持追逐夢(mèng)想，用汗水澆灌希望，在青春的歲月里綻放絢麗，譜寫(xiě)生命的壯麗樂(lè)章。

堅(jiān)持的力量塑造輝煌，奮斗的精神譜寫(xiě)傳奇。揚(yáng)起夢(mèng)想的風(fēng)帆，沖破人生的浪潮。挫折只是暫時(shí)的迷茫，努力則是前行的動(dòng)力。奮斗不止于口號(hào)，而是用行動(dòng)書(shū)寫(xiě)自己的傳世之篇，創(chuàng)造無(wú)限可能的精彩人生。

勇往直前，不畏困難，追逐內(nèi)心的夢(mèng)想和熱愛(ài)。用堅(jiān)持與努力書(shū)寫(xiě)人生華章，每一次奮斗都是收獲的種子。不止步于平凡，踏上征程，闖出自己的天空，讓奮斗之光點(diǎn)亮未來(lái)的道路。