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小時）運行的系統，至少應該能保證系統穩定運行８小時以上。對于7*24運行的系統，至少應該能夠保證系統穩定運行24小時以上。

標準

TPS曲線穩定，沒有大幅度的波動。

各項資源指標沒有泄露或異常情況。

?

7）批量處理指標：指批量處理程序單位時間內處理的數據數量。一般用每秒處理的數據量來衡量。

處理效率是估算批量處理時間窗口最重要的計算指標。

關于批量處理時間窗口，不同系統的批量處理時間窗口在起止時間上可以部分重疊。另外，同一系統內部，也可能存在多個批量處理過程同時進行，其時間窗口相互疊加。

標準

在數據量很大的情況下，批處理時間窗口時間越短越好。

不能影響實時交易系統性能。

?

8）可擴展性指標：指應用軟件或操作系統以群集方式部署，增加的硬件資源與增加的處理能力之間的關系。

計算公式為：（增加性能/原始性能）/（增加資源/原始資源）*100%。

擴展能力應通過多輪測試獲得擴展指標的變化趨勢。

標準

理想的擴展能力是資源增加幾倍，性能就提升幾倍。

擴展能力至少在70%以上。

?

9）可靠性指標：雙機熱備、集群、備份和恢復。

指標	測試內容
雙機熱備	節點切換是否成功及其消耗時間 雙機切換是否有業務中斷 節點回切是否成功及其耗時 雙機回切是否有業務中斷 節點回切過程中的數據丟失量
集群	集群中某個節點出現故障時，系統是否有業務中斷情況出現 在集群中新增一個節點時，是否需要重啟系統 當故障節點恢復后，加入集群，是否需要重啟系統 當故障節點恢復后，加入集群，系統是否有業務中斷情況出現 節點切換需要多長時間
備份和恢復	備份是否成功及其消耗時間 備份是否使用腳本自動化完成 恢復是否成功及其消耗時間 恢復是否使用腳本自動化完成

?

2.?具體性能的分析流程？

首先看關鍵指標是否滿足需求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種可能性非常小）。

如果是服務器端的問題，需要定位的問題有硬件相關指標，例如CPU，Memory，Disk I/O，Network I/O，如果是某個硬件指標有問題，需要深入的進行分析。如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查SQL，命中率，鎖，參數設置。

如果以上指標都正常，應用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。

?

3.?如果讓你去優化前端頁面，你的優化流程是？

遇到問題，第一步是確定問題，先要確定是前端的問題還是后端的問題。

如果是前端的問題，那就要確定在哪些地方出了問題，按照前端的各種檢測方法來檢查。

如果是后端的問題，就從系統、中間件、數據庫、網絡等方面入手。

如何確定問題呢？

比如用Firefox的firebug調試，看一次請求在各部分分別花了多少時間，哪些請求耗時最長。

如果請求的是靜態資源，時間很長，就需要考慮部署CDN啥的；

如果請求的不是靜態資源而是服務器數據，時間長速度慢，那就分兩種情況進行考慮：第一是后端的問題，第二是前端渲染問題。

如果返回數據很快，但界面數據沒出來，就要考慮是前端js程序問題還是圖片等資源太大的問題等等。

轉載于:https://www.cnblogs.com/malinalian/p/10583314.html

總結

以上是生活随笔為你收集整理的性能测试四十五：性能测试策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。