今天文章干貨滿(mǎn)滿(mǎn),松勤軟件測試帶大家一起來(lái)了解一下性能測試里的指標有哪些?
 
01
性能指標
 
 

 

TPS:啟動(dòng)一個(gè)壓測任務(wù),我們最開(kāi)始看到的監控數據是性能指標。如下tps曲線(xiàn)圖,繪制出來(lái)的是不同并發(fā)下tps數據,這里主要看的就是增加并發(fā)后tps能否平緩增加,如按一定比例上升,服務(wù)處理能力還未到瓶頸,如未到性能指標,可繼續增壓。如果是增加并發(fā)量tps不增或者下降,可能服務(wù)已經(jīng)過(guò)載。
響應時(shí)間:同時(shí)結合一起看的還有響應時(shí)間,如果增加并發(fā)后,tps增加,響應時(shí)間不增加,服務(wù)處理能力還未到瓶頸,如果增加并發(fā),tps不增加或者增加緩慢,這種情況響應時(shí)間也會(huì )增加,因為服務(wù)的處理能力一定到最大了,依據并發(fā)和響應時(shí)間成正比的關(guān)系,并發(fā)增加的同時(shí)響應時(shí)間會(huì )增加。
日常情況下看TP90,TP99,TP999的值。平均響應時(shí)間是個(gè)平均值,在值不均勻穩定的情況下,很容易把結果值拉低或者拉高。
 

 
錯誤率:除了上述指標我們還需要看請求通過(guò)率,在壓測期間,如果失敗的請求數較多,確認壓測腳本和參數無(wú)誤后,再看壓測平臺日志,是否有異?;蝈e誤報出,還有服務(wù)的error日志,依次確認失敗原因,直到錯誤率在一個(gè)合理的范圍內。
 

 
02
服務(wù)指標
 
 
 
 
啟動(dòng)壓測任務(wù)后,我們同時(shí)需要觀(guān)察服務(wù)的資源情況,良好的情況下,服務(wù)壓力增加,性能指標增加,服務(wù)資源消耗增加,但是有時(shí)候可能并非如此,下面介紹服務(wù)側應該看哪些指標。
 
(1)應用服務(wù)器資源,主要監控cpu、內存、磁盤(pán)、網(wǎng)絡(luò )帶寬。如果接口有復雜的算法、或者請求到一定的量、機器數量較少時(shí),cpu利用率可能會(huì )比較高;如果接口返回值較大,可能網(wǎng)絡(luò )帶寬會(huì )有一定的消耗;如果讀寫(xiě)操作比較多,如數據庫頻繁插入、更新,磁盤(pán)util%一般會(huì )增大,壓測前對業(yè)務(wù)邏輯有個(gè)了解,監控才能有側重點(diǎn)。
 
(2)應用服務(wù),大并發(fā)量的請求時(shí),時(shí)不時(shí)的刷一下error日志,看看是否有異常,大量的插庫是否有主鍵沖突等問(wèn)題。
 
(3)應用服務(wù)jvm虛擬機,啟動(dòng)java應用時(shí),會(huì )確定服務(wù)的初始堆內存、最大最內存、最小堆內存大小,以及內存回收的方式。目前平臺都會(huì )設置默認值,大部分情況下使用默認配置即可,不過(guò)如果某業(yè)務(wù)對吞吐量或者平響有較高要求,可能還需要調整新生代和老年代的大小比例,來(lái)保證GC回收造成的服務(wù)停止時(shí)間在指定的數值范圍內。
 
如下圖堆內存在一定時(shí)間回收后降到初始大小,基本可以確定無(wú)內存泄漏問(wèn)題;如果曲線(xiàn)整體呈遞增趨勢,那可能是內存對象回收不徹底,有內存泄漏的可能,確認該種問(wèn)題是否存在可以調小堆內存的大小,對接口發(fā)請求,同時(shí)觀(guān)察回收曲線(xiàn)。還有關(guān)注下新生代、老年代回收次數是否頻繁,FGC每次回收時(shí)間是否較長(cháng)(超過(guò)1s)。
 

 
(4)數據庫服務(wù)除了上述資源指標,還要關(guān)注查tps,寫(xiě)tps,慢查詢(xún)的統計,是否有主從延時(shí)的情況等。如有時(shí)候服務(wù)端統計到的tps只有1000,數據庫統計到的tps倍數很大,可能存在一次請求多次操作數據庫、操作數據庫太頻繁的問(wèn)題。慢查詢(xún)的話(huà)可能是沒(méi)建索引,或者是建了索引,因索引不合理未走索引,還有可能是數據庫數據量太大,索引也很大,影響了性能。
 
(5)正式鏈路中可能還會(huì )有jen層,發(fā)起壓測任務(wù)后,請運維同學(xué)協(xié)助看jen層的耗時(shí)、keep-alive鏈接數、帶寬消耗等信息。
 
03
緩存中間件
 
 
 
 
為了提升服務(wù)的性能,大部分架構都會(huì )用到緩存中間件,項目中一般使用r2m,因r2m本身性能較好,大量請求下觀(guān)察r2m各分片負載是否均勻,是否存在大key問(wèn)題、tps突增突降、慢日志等。
 
還有寫(xiě)操作請求量較大時(shí),r2m內存被使用量到一定的量(80%左右),可能會(huì )啟動(dòng)自動(dòng)擴容策略,在擴容期間請求會(huì )受影響,這種也會(huì )對性能有一定的影響。
 
消息隊列的還需要關(guān)注消息數是否堆積、消費側的消費能力,這種情況下tps可能不能按服務(wù)的請求量來(lái)算,而應該用消費的量來(lái)算。
 
04
壓力機指標
 
 
 
 
就公司目前的壓測平臺來(lái)說(shuō),極少會(huì )發(fā)生壓力機過(guò)載的情況,不過(guò)因為壓測任務(wù)參數配置不合適,可能會(huì )出現該種問(wèn)題。啟動(dòng)任務(wù)后,觀(guān)察一下壓力機負載情況,還有壓力機的日志。
(1)發(fā)壓配置
以forcbot為例,壓力機線(xiàn)程總數=單機壓力機最大線(xiàn)程數*單機最大進(jìn)程數,壓力機的負載主要是任務(wù)的單機線(xiàn)程數和最大進(jìn)程數的大小來(lái)影響的,如果配置較小壓力不夠,壓力機負載低,同時(shí)tps可能也上不去,配置較大壓力機負載過(guò)高,成為瓶頸。在壓測期間觀(guān)察壓力機的負載,讓該值保持在50%左右,如果負載較高,就調小單機線(xiàn)程或者進(jìn)程,小則反之。
 

 
(2)壓力機監控
如下是壓力機的cpu使用率,在整個(gè)壓測期間最高15%,大部分是6%左右,可以排除壓力機瓶頸。
 
 

 
05
監控告警
 
 
 
除了常見(jiàn)的監控指標,還有一個(gè)不能忽略的就是看監控告警,壓測期間服務(wù)告警不要關(guān)閉,以防出現問(wèn)題不能發(fā)現。