測試分析及調優

在負載情況下訊息伺服器時間特性的測試伺服器的測試分析過程，在測試過程中通過分析被測物件及測試結果，設計測試方法及測試資料，找出被測物件的效能瓶頸所在，達到優化系統效能的目的。

本文通過編寫效能測試分析及調優的相關流程和方法，幫助研發人員、效能測試人員或者運維人員快速地進行效能測試、瓶頸定位及調優。系統的效能是由很多因素決定的，本文很難面面俱到，但是可以作為分析系統效能的乙個指導。

適用於需要進行效能分析及調優的工作。預期讀者為測試管理人員、測試實施人員、技術支援人員、專案質量管理人員、專案管理人員等系統技術質量相關人員。

前提效能分析的前提除了需要豐富的效能測試監控（如pts自身的客戶側監控、基礎類監控-阿里雲監控、應用類監控-arms監控等），還需要具備相關的技術知識（包括但不限於：作業系統、中介軟體、資料庫、開發等）。

流程具體如下圖所示：

可能瓶頸點硬體、規格上的瓶頸

一般指的是cpu、記憶體、磁碟i/o方面的問題，分為伺服器硬體瓶頸、網路瓶頸（對區域網可以不考慮）。

中介軟體上的效能瓶頸

一般指的是應用伺服器、web伺服器等應用軟體，還包括資料庫系統。例如：中介軟體weblogic平台上配置的jdbc連線池的引數設定不合理，造成的瓶頸。

應用程式上的效能瓶頸

一般指的是開發人員開發出來的應用程式。例如，jvm引數不合理，容器配置不合理，慢sql（可使用阿里雲apm類產品如arms協助定位），資料庫設計不合理，程式架構規劃不合理，程式本身設計有問題（序列處理、請求的處理執行緒不夠、無緩衝、無快取、生產者和消費者不協調等），造成系統在大量使用者訪問時效能低下而造成的瓶頸。

作業系統上的效能瓶頸

一般指的是windows、unix、linux等作業系統。例如，在進行效能測試，出現物理記憶體不足時，虛擬記憶體設定也不合理，虛擬記憶體的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為作業系統上出現效能瓶頸。

網路裝置上的效能瓶頸

一般指的是防火牆、動態負載均衡器、交換機等裝置。當前更多的雲化服務架構使用的網路接入產品：包括但不限於slb、waf、高防ip、cdn、全站加速等等。例如，在動態負載均衡器上設定了動態分發負載的機制，當發現某個應用伺服器上的硬體資源已經到達極限時，動態負載均衡器將後續的交易請求傳送到其他負載較輕的應用伺服器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網路瓶頸。

方法cpu

cpu資源利用率很高的話，需要看cpu消耗user、sys、wait哪種狀態。

memory

作業系統為了最大化利用記憶體，一般都設定大量的cache，因此，記憶體利用率高達99%並不是問題，記憶體的問題主要看某個程序占用的記憶體是否非常大以及是否有大量的swap（虛擬記憶體交換）。

磁碟i/o

磁碟i/o乙個最顯著的指標是繁忙率，可以通過減少日誌輸出、非同步或換速度快的硬碟來降低繁忙率。

網路i/o

網路i/o主要考慮傳輸內容大小，不能超過硬體網路傳輸的最大值70%，可以通過壓縮減少內容大小、在本地設定快取以及分多次傳輸等操作提高網路i/o效能。

核心引數

核心引數一般都有預設值，這些核心引數預設值對於一般系統沒問題，但是對於壓力測試來說，可能執行的引數將會超過核心引數，導致系統出現問題，可以用sysctl來檢視及修改。

jvmjvm主要分析gc/full gc是否頻繁，以及垃圾**的時間，可以用jstat命令來檢視，對於每個代大小以及gc頻繁，通過jmap將記憶體轉儲，再借助工具heapanalyzer來分析哪地方占用的記憶體較高以及是否有記憶體洩漏可能。簡單點可以使用apm工具，例如阿里雲arms。

執行緒池如果執行緒不夠用，可以通過引數調整，增加執行緒；對於執行緒池中的執行緒設定比較大的情況，還是不夠用可能的原因是：某個執行緒被阻塞來不及釋放，可能在等鎖、方法耗時較長、資料庫等待時間很長等原因導致，需要進一步分析才能定位。

jdbc連線池

連線池不夠用的情況下，可以通過引數進行調整增加；但是對於資料庫本身處理很慢的情況下，調整沒有多大的效果，需要檢視資料庫方面以及因**導致連線未釋放的原因。

sqlsql效率低下也是導致效能差的乙個非常重要的原因，可以通過檢視執行計畫看sql慢在**，一般情況，sql效率低下原因主要有：

類別子類

表示式或描述

原因索引

未建索引

無產生全表掃瞄

未利用索引

substring(card_no,1,4)=′5378′

產生全表掃瞄

amount/30< 1000

產生全表掃瞄

convert(char(10),date,112)=′19991201′

產生全表掃瞄

where salary<>3000

產生全表掃瞄

name like '%張'

產生全表掃瞄

first_name + last_name ='beill cliton'

產生全表掃瞄

id_no in(′0′,′1′)

產生全表掃瞄

select id from t where num=@num

有引數也會產生全表掃瞄

使用效能低的索引

oder by非聚族索引

索引效能低

username='張三'and age>20

字串索引低於整形索引

表中列與空null值

索引效能低

盡量不要使用is null或is not null

索引效能低

資料量所有資料量

select *

很多列產生大量資料

select id,name

表中有幾百萬行，產生大量資料

巢狀查詢

先不過濾資料，後過濾資料

產生大量無用的資料

關聯查詢

多表進行關聯查詢，先過濾掉小部分資料，在過濾大部分資料

大量關聯操作

大資料量插入

一次次插入

產生大量日誌，消耗資源

鎖鎖等待

update account set banlance=100 where id=10

產生表級鎖，將會鎖住整個表

死鎖a:update a;update b;b:update b;update a;

將會產生死鎖

游標cursor open cursor,fetch;close cursor

效能很低

臨時表create tmp table建立臨時表

產生大量日誌

drop table

刪除臨時表

需要顯示刪除，避免系統表長時間鎖定

其他exist代替in

select num from a where num in(select num from b)

in會逐個判斷，exist有一條就結束

exist代替select count(*)

判斷記錄是否存在

count(*) 將累加計算，exist有就結束

between代替in

id in(1,2,3)

in逐個判斷，between是範圍判斷

left outer join代替not in

select id from a where id not in(select b.mainid from b)

not in逐個判斷，效率非常低

union all代替union

select id from a union select id from b union

刪除重複的行，可能會在磁碟進行排序而union all只是簡單的將結果並在一起

常用sql盡量用繫結變數方法

insert into a(id) values(1)

直接寫sql每次都要編譯，用繫結變數的方法只編譯一次，下次就可以用了

調優步驟確定問題

分析問題

通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因。

確定調整目標和解決方案

高系統吞吐量，縮短響應時間，更好地支援併發。

測試解決方案

對通過解決方案調優後的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試物件的某項效能指標進行定量的和可對比的測試）。

分析調優結果

系統調優是否達到或者超出了預定目標；系統是整體效能得到了改善，還是以系統某部分效能來解決其他問題；調優是否可以結束了。最後，如果達到了預期目標，調優工作可以先告一段落。

調優注意事項

測試分析及調優

效能測試常見瓶頸分析及調優方法

效能測試調優

MySQL效能測試調優

測試分析及調優

效能測試常見瓶頸分析及調優方法

效能測試調優

MySQL效能測試調優

相關推薦