性能測試四十五:性能測試策略
1、項目具體需求,及業務場景:關註真實用戶會是怎樣的一個業務場景,確定用戶的用戶習慣。
2、指標:響應時間在多少以內,並發數多少,tps多少,總tps多少,穩定性交易總量多少,事務成功率,交易波動範圍,穩定運行時長,資源利用率,測哪些交易,哪些接口,測試哪些場景。
3、環境:生產環境服務器數量,測試環境服務器數量,按照資源配比得出測試指標。
4、協議:系統用什麽協議進行通訊。
5、壓力機數量:如果並發用戶數太多,需要把壓力發到不同的壓力機,不然可能會存在壓力機瓶頸問題,導致tps和響應時間抖動。
6、交易占比:分析線上日誌得出tps占比。
7、系統架構:請求流經過哪些環節,壓測時監控這些環節。
測試
1、基準:一個用戶叠代100次,關註響應時間,事務成功率100%。
2、負載:10個用戶跑10分鐘,關註響應時間,事務成功率100%。
3、容量:估算一個總tps,根據公式計算出每個交易的pacing和vu,獲取系統最大處理能力(最優容量),再令外測出三個梯度作為對比(兩組小於最優容量,一組大於最優容量),四組容量VU等差,tps等差,對比每組容量實際占比和測試占比(越接近越能模擬真實場景),關註響應時間,總tps,tps,事務成功率,AP cpu利用率,DB cpu利用率,線程死鎖,數據庫死鎖。
其中響應時間應小於負載測試時間,總tps應約等於預估總tps(相差不超過10是正常的),每個交易的tps應接近預估總tps*占比,事務成功率100%,AP cpu小於60%,DB cpu小於80%。dump線程棧檢測是否有線程死鎖,查看數據庫日誌看是否有數據庫死鎖。
4、穩定性:采取最優容量的80%作為壓力持續運行24小時,觀察系統長時間運行的性能表現,關註響應時間,tps,總tps,事務成功率,交易總數,觀察是否有內存溢出(堆溢出,棧溢出,持久代溢出),cpu利用率是否達標,mem是否不持續增長,是否能正常觸發fullgc,gc時間,gc頻率, fullgc時間,fullgc頻率(重點關註,JVM調優就是為了減少fullgc頻率)。
壓測中遇到的性能問題及解決辦法
一、測試過程中cpu過高
1、用vmstat實時監控cpu使用情況。很小的壓力AP cpu卻到了80%多,指標是不能超過60%。
2、分析是use cpu過高還是sys cpu過高,常見的是use cpu使用過高。
3、如果是sys cpu使用過高,先把消耗cpu最多的進程找出來(top命令),再找到該線程下消耗cpu過高的是哪幾個線程,再把該線程轉換成16進制,再用jstack命令來dump線程棧,看這個線程棧在調用什麽東西導致use cpu過高。
二、內存溢出(堆溢出、棧溢出、持久代溢出)
1、堆內存溢出
1)穩定性壓測一段時間後,LR報錯,日誌報java.lang.OutOfMemoryError.Java heap space。
2)用jmap -histo pid命令dump堆內存使用情況,查看堆內存排名前20個對象,看是否有自己應用程序的方法,從最高的查起,如果有則檢查該方法是什麽原因造成堆內存溢出。
3)如果前20裏沒有自己的方法,則用jmap -dump來dump堆內存,在用MAT分析dump下來的堆內存,分析導出內存溢出的方法。
4)如果應用程序的方法沒有問題,則需要修改JVM參數,修改xms,xmx,調整堆內存參數,一般是增加堆內存。
2、棧內存溢出
1)穩定性壓測一段時間後,LR報錯,日誌報Java.Lang.StackOverflowError。
2)修改jvm參數,將xss參數改大,增加棧內存。
3)棧溢出一定是做批量操作引起的,減少批處理數據量。
3、持久代溢出
1)穩定性壓測一定時間後,日誌報Java.Lang.OutOfMenoryError.PermGen Space。
2)這種原因是由於類、方法描述、字段描述、常量池、訪問修飾符等一些靜態變量太多,將持久代占滿導致持久代溢出。
3)修改jvm配置,將XX:MaxPermSize=256參數調大。盡量減少靜態變量。
三、線程死鎖
1、容量測試壓測一段時間後,LR報連接超時。
2、造成這種現象的原因很多,比如帶寬不夠,中間件線程池不夠用,數據庫連接池不夠,連接數占滿等都會造成連接不上而報超時錯誤。
3、jstack命令dump線程棧,搜索線程棧裏有沒有block,如果有的話就是線程死鎖,找到死鎖的線程,分析對應的代碼。
四、數據庫死鎖
1、容量測試壓測一段時間後,LR報連接超時。
2、造成這種現象的原因很多,比如帶寬不夠,中間件線程池不夠用,數據庫連接池不夠,連接數占滿等都會造成連接不上而報超時錯誤。
3、數據庫日誌中搜索block,能搜到block的話就是存在數據庫死鎖,找到日誌,查看對應的sql,優化造成死鎖的sql。
五、數據庫連接池不釋放
1、容量測試壓測一段時間後,LR報連接超時。
2、造成這種現象的原因很多,比如帶寬不夠,中間件線程池不夠用,數據庫連接池不夠,連接數占滿等都會造成連接不上而報超時錯誤。
3、去數據庫查看應用程序到數據庫的連接有多少個( show full processlist),假如應用程序裏面配置的數據庫連接為30,在數據庫查看應用程序到數據庫的連接也是30,則表示連接池占滿了。將配置改成90試試,去數據庫看如果連接到了90,則可以確定是數據庫連接池不釋放導致的。查看代碼,數據庫連接部分是不是有創建連接但是沒有關閉連接的情況。基本就是這種情況導致的,修改代碼即可。
六、TPS上不去
1、壓力大的時候tps頻繁抖動,導致總tps上不去。查看是否有fullgc(tail -f gc_mSrv1.log | grep full)。
2、pacing設置太小也會導致tps上不去,對抖動大的交易多增加點用戶即可。
3、tps抖動,單壓抖動大的交易,發現很平穩,這時懷疑是不是壓力太大導致,所以發容量的時候把壓力最大的那只交易分到其他壓力機,然後發現tps不抖動了。註意:多臺壓力機只影響tps抖動,不會影響服務器的cpu。
4、看響應時間有沒有超時,看用戶數夠不夠。
七、服務器壓力不均衡(相差1%-2%是正常的)
1、跑最優容量的時候,四臺AP只有一臺cpu超過60%,其他三臺都在60%以下。
2、查看服務器是否有定時任務。
3、查看是否存在壓力機瓶頸。
4、是否存在帶寬瓶頸(局域網不存在此問題)。
5、查看部署的版本,配置是否一樣。
6、可能別人也在用這些AP,因為同一臺物理機上有很多虛擬機,因為別人先用,資源被別人先占了。
八、fullgc時間太長
1、跑容量和穩定性的時候,出現LR報請求超時錯誤,查看後臺日誌是fullgc了,看LR幾點報的錯和日誌裏fullgc的時間是否對應,fullgc會暫停整個應用程序,導致LR前端沒響應,所以報錯,這時可以減少old代內存,從而減少fullgc時間,減少fullgc時間LR就不會報錯,讓用戶幾乎感覺不到應用程序暫停。
2、四臺AP輪流著full gc(部分server fullgc,其他server也會fullgc),這時可以制定策略讓不同的server不同時fullgc,或者等夜間交易量少時寫定時任務重啟服務。
十、系統性能指標
1)業務指標:主要包括並發用戶數、響應時間、處理能力。
指標 |
定義 |
簡稱 |
標準 |
交易響應時間 |
指用戶從客戶端發起一個請求開始,到客戶端接收到從服務器端返回的響應結束,整個過程所耗費的時間。 |
Response Time: RT |
對於在線實時交易: 互聯網企業:500毫秒以下,例如淘寶業務10毫秒左右。 金融企業:1秒以下為佳,部分復雜業務3秒以下。 保險企業:3秒以下為佳。 制造業:5秒以下為佳。 對於批量交易: 不同數據量結果是不一樣的,大數據量的情況下,2小時內完成。 |
系統處理能力 |
指系統在利用系統硬件平臺和軟件平臺進行信息處理的能力。 系統處理能力通過系統每秒鐘能夠處理的交易數量來評價,交易有兩種理解:一是業務人員角度的一筆業務過程;二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程,後者稱為事務。兩種交易指標都可以評價應用系統的處理能力。一般建議與系統交易日誌保持一致,以便於統計業務量或者交易量。 |
HPS(Hits Per Second) :每秒點擊次數,單位是次/秒。 TPS(Transaction per Second):系統每秒處理交易數,單位是筆/秒。 QPS(Query per Second):系統每秒處理查詢次數,單位是次/秒。 對於互聯網業務中,如果某些業務有且僅有一個請求連接,那麽TPS=QPS=HPS。 一般情況下,用TPS來衡量整個業務流程,用QPS來衡量接口查詢次數,用HPS來表示對服務器點擊請求。 |
無論TPS、QPS、HPS,此指標是衡量系統處理能力非常重要的指標,越大越好。 |
並發用戶數 |
指在同一時刻內,登錄系統並進行業務操作的用戶數量。在測試中,采用虛擬用戶來模擬現實中用戶進行業務操作。 |
Virtual User: VU |
一般情況下,性能測試是將系統處理能力容量測出來,而不是測試並發用戶數,除了服務器長連接可能影響並發用戶數外,系統處理能力不受並發用戶數影響,可以用最小的用戶數將系統處理能力容量測試出來,也可以用更多的用戶將系統處理能力容量測試出來。 |
錯誤率 |
指系統在負載情況下,失敗交易的概率。 錯誤率=(失敗交易數/交易總數)*100%。 穩定性較好的系統,其錯誤率應該由超時引起,即為超時率。 |
Failure Ratio: FR |
不同系統對錯誤率的要求不同,但一般不超出千分之六,即成功率不低於99.4%。 |
2)資源指標:CPU資源利用率、內存利用率、磁盤I/O、網絡I/O、內核參數(信號量、打開文件數)等。
指標 |
定義 |
簡稱 |
標準 |
CPU |
中央處理器是一塊超大規模的集成電路,是一臺計算機的運算核心(Core)和控制核心( Control Unit)。它的功能主要是解釋計算機指令以及處理計算機軟件中的數據。 |
Central Processing Unit:CPU |
CPU指標主要指的CPU利用率,包括用戶態(user)、系統態(sys)、等待態(wait)、空閑態(idle)。 CPU利用率要低於業界警戒值範圍之內,即小於或者等於75%; CPU sys%小於或者等於30%, CPU wait%小於或者等於5%。 CPU Load要小於CPU 核數。 |
內存 |
內存是計算機中重要的部件之一,它是與CPU進行溝通的橋梁。計算機中所有程序的運行都是在內存中進行的,因此內存的性能對計算機的影響非常大。 |
Memory就是內存的簡稱 |
現代的操作系統為了最大利用內存,在內存中存放了緩存,因此內存利用率100%並不代表內存有瓶頸,衡量系統內有有瓶頸主要靠SWAP(與虛擬內存交換)交換空間利用率,一般情況下,SWAP交換空間利用率要低於70%,太多的交換將會引起系統性能低下。 |
磁盤吞吐量 |
指在無磁盤故障的情況下單位時間內通過磁盤的數據量。 |
Disk Throughput |
磁盤指標主要有每秒讀寫多少兆,磁盤繁忙率,磁盤隊列數,平均服務時間,平均等待時間,空間利用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的的重要依據,一般情況下,磁盤繁忙率要低於70%。 |
網絡吞吐量 |
指在無網絡故障的情況下單位時間內通過的網絡的數據數量。單位為Byte/s。用於衡量系統對於網絡設備或鏈路傳輸能力的需求。 當網絡吞吐量指標接近網絡設備或鏈路最大傳輸能力時,則需要考慮升級網絡設備。 |
Network Throughput |
網絡吞吐量指標主要有每秒有多少兆流量進出,一般情況下不能超過設備或鏈路最大傳輸能力的70%。 |
3)中間件指標:常用的中間件例如Tomcat、Weblogic等指標主要包括JVM, ThreadPool, JDBC。
指標 |
二級指標 |
解釋 |
單位 |
GC |
GC頻率 |
java虛擬機垃圾部分回收頻率 |
每秒多少次 |
Full GC頻率 |
java虛擬機垃圾完全回收頻率 |
每小時多少次 |
|
Full GC平均時長 |
用於垃圾完全回收的平均時長 |
秒 |
|
Full GC最大時長 |
用於垃圾完全回收的最大時長 |
秒 |
|
ThreadPool |
Active Thread Count |
活動的線程數 |
個 |
Pending User Request |
處於排隊的用戶請求個數 |
個 |
|
JDBC |
JDBC Active Connection |
JDBC活動連接數 |
個 |
標準
當前正在運行的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下,線程數最小值設置50和最大值設置200比較合適。
當前運行的JDBC連接數不能超過設定的最大值。一般情況下系統性能較好的情況下,JDBC最小值設置50和最大值設置200比較合適。
GC頻率不能頻繁,特別是FULL GC更不能頻繁,一般情況下系統性能較好的情況下,JVM最小堆大小和最大。
4)數據庫指標:SQL、吞吐量、命中率、鎖。
指標 |
二級指標 |
解釋 |
單位 |
SQL |
耗時 |
執行SQL耗時 |
微秒 |
吞吐量 |
QPS |
每秒查詢次數 |
個 |
TPS |
每秒事務次數 |
個 |
|
命中率 |
Key Buffer命中率 |
索引緩沖區命中率 |
百分之 |
InnoDB Buffer命中率 |
InnoDB緩沖區命中率 |
百分之 |
|
Query Cache命中率 |
查詢緩存命中率 |
百分之 |
|
Table Cache命中率 |
表緩存命中率 |
百分之 |
|
Thread Cache命中率 |
線程緩存命中率 |
百分之 |
標準
SQL耗時越小越好,一般情況下微秒級別。
命中率越高越好,一般情況下不能低於95%。
鎖等待次數越低越好,等待時間越短越好。
5)前端指標:頁面加載時間、頁面數量、網絡時間(DNS,連接時間、傳輸時間等)。
指標 |
二級指標 |
解釋 |
單位 |
頁面展示 |
首次顯示時間 |
在瀏覽器地址欄輸入URL按回車到用戶看到網頁的第一個視覺標誌為止 |
毫秒 |
OnLoad事件時間 |
瀏覽器觸發onLoad事件的時間,當原始文檔和所有引用的內容完全下載後才會觸發這個事件 |
毫秒 |
|
完全載入的時間 |
所有onLoad JavaScript 處理程序執行完畢,所有動態的或延遲加載的內容都通過這些處理程序觸發的時間 |
毫秒 |
|
頁面數量 |
頁面大小 |
整個頁面大小 |
KB |
請求數量 |
從網站下載資源時所有網絡請求的總數,盡量少 |
次 |
|
網絡所花時間 |
DNS時間 |
DNS查找時間 |
毫秒 |
連接時間 |
瀏覽器與Web服務器建立TCP/IP連接的時間 |
毫秒 |
|
服務器時間 |
服務器處理時間 |
毫秒 |
|
傳輸時間 |
內容傳輸所用時間 |
毫秒 |
|
等待時間 |
等待某個資源釋放的時間 |
毫秒 |
標準
頁面要盡可能小及壓縮。
頁面展示和花費時間越短越好。
6)穩定性指標
最短穩定時間:系統按照最大容量的80%或標準壓力(系統的預期日常壓力)情況下運行,能夠穩定運行的最短時間。
一般來說,對於正常工作日(8小時)運行的系統,至少應該能保證系統穩定運行8小時以上。對於7*24運行的系統,至少應該能夠保證系統穩定運行24小時以上。
標準
TPS曲線穩定,沒有大幅度的波動。
各項資源指標沒有泄露或異常情況。
7)批量處理指標:指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。
處理效率是估算批量處理時間窗口最重要的計算指標。
關於批量處理時間窗口,不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外,同一系統內部,也可能存在多個批量處理過程同時進行,其時間窗口相互疊加。
標準
在數據量很大的情況下,批處理時間窗口時間越短越好。
不能影響實時交易系統性能。
8)可擴展性指標:指應用軟件或操作系統以群集方式部署,增加的硬件資源與增加的處理能力之間的關系。
計算公式為:(增加性能/原始性能)/(增加資源/原始資源)*100%。
擴展能力應通過多輪測試獲得擴展指標的變化趨勢。
標準
理想的擴展能力是資源增加幾倍,性能就提升幾倍。
擴展能力至少在70%以上。
9)可靠性指標:雙機熱備、集群、備份和恢復。
指標 |
測試內容 |
雙機熱備 |
節點切換是否成功及其消耗時間 雙機切換是否有業務中斷 節點回切是否成功及其耗時 雙機回切是否有業務中斷 節點回切過程中的數據丟失量 |
集群 |
集群中某個節點出現故障時,系統是否有業務中斷情況出現 在集群中新增一個節點時,是否需要重啟系統 當故障節點恢復後,加入集群,是否需要重啟系統 當故障節點恢復後,加入集群,系統是否有業務中斷情況出現 節點切換需要多長時間 |
備份和恢復 |
備份是否成功及其消耗時間 備份是否使用腳本自動化完成 恢復是否成功及其消耗時間 恢復是否使用腳本自動化完成 |
2. 具體性能的分析流程?
首先看關鍵指標是否滿足需求,如果不滿足,需要確定是哪個地方有問題,一般情況下,服務器端問題可能性比較大,也有可能是客戶端問題(這種可能性非常小)。
如果是服務器端的問題,需要定位的問題有硬件相關指標,例如CPU,Memory,Disk I/O,Network I/O,如果是某個硬件指標有問題,需要深入的進行分析。如果中間件相關指標沒問題,需要查看數據庫相關指標,例如:慢查SQL,命中率,鎖,參數設置。
如果以上指標都正常,應用程序的算法、緩沖、緩存、同步或異步可能有問題,需要具體深入的分析。
3. 如果讓你去優化前端頁面,你的優化流程是?
遇到問題,第一步是確定問題,先要確定是前端的問題還是後端的問題。
如果是前端的問題,那就要確定在哪些地方出了問題,按照前端的各種檢測方法來檢查。
如果是後端的問題,就從系統、中間件、數據庫、網絡等方面入手。
如何確定問題呢?
比如用Firefox的firebug調試,看一次請求在各部分分別花了多少時間,哪些請求耗時最長。
如果請求的是靜態資源,時間很長,就需要考慮部署CDN啥的;
如果請求的不是靜態資源而是服務器數據,時間長速度慢,那就分兩種情況進行考慮:第一是後端的問題,第二是前端渲染問題。
如果返回數據很快,但界面數據沒出來,就要考慮是前端js程序問題還是圖片等資源太大的問題等等。
性能測試四十五:性能測試策略