閱讀568 返回首頁    go 魔獸

測試分析及調優__性能測試技術體係_性能測試體係_性能測試-阿裏雲

訪問性能測試控製台

1 引言

1.1 編寫目的

本文通過編寫性能測試分析及調優相關流程和方法，幫助性能測試人員很快的進行性能測試瓶頸定位及調優。
係統的性能是由很多因素決定的，本文不可能將每種瓶頸和調優說的非常清楚，但是可以指導怎麼去分析係統的性能。

1.2 適用對象和範圍

適用於使用性能測試進行性能測試項目性能分析及調優依據。
預期讀者為測試管理人員、測試實施人員、技術支持人員、項目質量管理人員、項目管理人員等係統技術質量相關人員。

2 性能分析

2.1 前提

性能分析的前提是不僅需要性能測試人員有相關的技術知識（例如：操作係統、中間件、數據庫、開發等），而且還需要豐富的性能測試監控（請參照:性能測試監控）。

2.2 流程

  • 關鍵指標是否滿足要求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種情況非常小）。
  • 對於服務器端問題，需要定位的是硬件相關指標，例如CPU，Memory, Disk I/O, Network I/O, 如果是某個硬件指標有問題，需要深入的進行分析。
  • 如果硬件指標都沒有問題，需要查看中間件相關指標，例如：線程池、連接池、GC等，如果是這些指標問題，需要深入的 分析。
  • 如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查SQL，命中率，鎖、參數設置。
  • 如果以上指標都正常，應用程序的算法、緩衝、緩存、同步或異步可能有問題，需要具體深入的分析。

具體如下圖所示：

2.3 可能瓶頸點

2.3.1 硬件上的性能瓶頸

一般指的是CPU、內存、磁盤I/O 方麵的問題，分為服務器硬件瓶頸、網絡瓶頸（對局域網可以不考慮）、服務器操作係統瓶頸（參數配置）、中間件瓶頸（參數配置、數據庫、web服務器等）、應用瓶頸（SQL 語句、數據庫設計、業務邏輯、算法等）。

2.3.2 中間件上的性能瓶頸

一般指的是應用服務器、web 服務器等應用軟件，還包括數據庫係統。
例如：中間件weblogic 平台上配置的JDBC連接池的參數設置不合理，造成的瓶頸。

2.3.3 應用程序上的性能瓶頸

一般指的是開發人員新開發出來的應用程序。
例如，程序架構規劃不合理，程序本身設計有問題（串行處理、請求的處理線程不夠、無緩衝、無緩存、生產者和消費者不協調等），造成係統在大量用戶方位時性能低下而造成的瓶頸。

2.3.4 操作係統上的性能瓶頸

一般指的是windows、UNIX、Linux等操作係統。
例如，在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而導致行為的響應時間大大增加，這時認為操作係統上出現性能瓶頸。

2.3.5 網絡設備上的性能瓶頸

一般指的是防火牆、動態負載均衡器、交換機等設備。
例如，在動態負載均衡器上設置了動態分發負載的機製，當發現某個應用服務器上的硬件資源已經到達極限時，動態負載均衡器將後續的交易請求發送到其他負載較輕的應用服務器上。在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認為網絡瓶頸。

2.4 方法

2.4.1 CPU

CPU資源利用率很高的話，需要看CPU消耗User,Sys,Wait那種狀態下。

  • 如果CPU User非常高，需要查看消耗在哪個進程，可以用top(linux)命令看出，接著用top –H –p <pid>看哪個線程消耗資源高，如果是java應用，就可以用jstack看出此線程正在執行的堆棧，看資源消耗在哪個方法上，查看源代碼就知道問題所在；如果是c++應用，可以用gprof性能工具進行分析。
  • 如果CPU Sys非常高，可以用strace(linux)看係統調用的資源消耗及時間。
  • 如果CPU Wait非常高，考慮磁盤讀寫了，可以通過減少日誌輸出、異步或換速度快的硬盤。

2.4.2 Memory

操作係統未了最大化利用內存，一般都設置大量的cache,因此，內存利用率高達99%並不是問題，內存的問題主要看某個進程占用的內存是否非常大以及是否有大量的swap(虛擬內存交換)。

2.4.3 磁盤I/O

磁盤I/O一個最顯著的指標是繁忙率，可以通過減少日誌輸出、異步或換速度快的硬盤。

2.4.4 網絡I/O

網絡I/O主要考慮傳輸內容大小，不能超過硬件網絡傳輸的最大值70%，可以通過壓縮、減少內容大小、在本地設置緩存以及分多次傳輸等。

2.4.5 內核參數

內核參數一般都有默認值，這些內核參數默認值對於一般係統沒問題，但是對於壓力測試來說，可能運行的參數將會超過內核參數，導致係統出現問題，可以用sysctl來查看及修改。

2.4.6 JVM

jvm主要分析GC/FULL GC是否頻繁，以及垃圾回收的時間，可以用jstat命令來查看，對於每個代大小以及GC頻繁，通過jmap將內存dump,再借助工具HeapAnalyzer來分析哪地方占用的內存較高以及是否有內存泄漏可能。

2.4.7 線程池

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

2.4.8 JDBC連接池

連接池不夠用的情況下，可以通過參數進行調整增加；但是對於數據庫本身處理很慢的情況下，調整沒有多大的效果，需要查看數據庫方麵以及因代碼導致連接未釋放的原因。

2.4.9 SQL

SQL效率低下也是導致性能差的一個非常重要的原因，可以通過查看執行計劃看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每次都要編譯，用綁定變量的方法隻編譯一次，下次就可以用了

3 調優

3.1 調優步驟

3.1.1 確定問題

應用程序代碼：在通常情況下，很多程序的性能問題都是寫出來的，因此對於發現瓶頸的模塊，應該首先檢查一下代碼。
數據庫配置：經常引起整個係統運行緩慢，一些諸如大型數據庫都是需要DBA進行正確的參數調整才能投產的。
操作係統配置：不合理就可能引起係統瓶頸。
硬件設置：硬盤速度、內存大小等都是容易引起瓶頸的原因，因此這些都是分析的重點。 網絡：網絡負載過重導致網絡衝突和網絡延遲。

3.1.2 分析問題

當確定了問題之後，我們要明確這個問題影響的是響應時間吞吐量，還是其他問題？是多數用戶還是少數用戶遇到了問題？如果是少數用戶，這幾個用戶與其它用戶的操作有什麼不用？係統資源監控的結果是否正常？CPU的使用是否到達極限？I/O 情況如何？問題是否集中在某一類模塊中？ 是客戶端還是服務器出現問題？ 係統硬件配置是否夠用？實際負載是否超過了係統的負載能力？ 是否未對係統進行優化？ 通過這些分析及一些與係統相關的問題，可以對係統瓶頸有更深入的了解，進而分析出真正的原因。

3.1.3 確定調整目標和解決方案

高係統吞吐量，縮短響應時間，更好地支持並發。

3.1.4 測試解決方案

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

3.1.5 分析調優結果

係統調優是否達到或者超出了預定目標？係統是整體性能得到了改善，還是以係統某部分性能來解決其他問題。調優是否可以結束了。 最後，如果達到了預期目標，調優工作就基本可以結束了。

3.2 調優注意事項

  • 在應用係統的設計開發過程中，應始終把性能放在考慮的範圍內。
  • 確定清晰明確的性能目標是關鍵。
  • 必須保證調優後的程序運行正確。
  • 係統的性能更大程度上取決於良好的設計，調優技巧隻是一個輔助手段。
  • 調優過程是迭代漸進的過程，每一次調優的結果都要反饋到後續的代碼開發中去。
  • 性能調優不能以犧牲代碼的可讀性和可維護性為代價

訪問性能測試控製台

最後更新：2016-05-06 10:44:40

  上一篇：go 測試監控__性能測試技術體係_性能測試體係_性能測試-阿裏雲
  下一篇：go 並發用戶和TPS關係__性能測試技術體係_性能測試體係_性能測試-阿裏雲