性能需求分析

原文地址：http://blog.sina.com.cn/s/blog_639aa08501010kkr.html

1.1      性能測試需求內容

性能測試需求應包括如下內容：

a)    測試場景及用例，用例訪問URL；

b)   目標接口方法的入參、出參；

c)    外部依賴的服務細節；

d)  關鍵數據: 數據量、高峯業務PV量

e)  預期性能指標：響應時間、QPS、TPS等

 

   性能測試需求模板表格參考以下：

1.2 預期性能指標

1.2.1數據量

測試環境的數據量，應該跟線上環境保持一致，至少要在一個數量級。

  舉例有，中文站線上的每秒登陸用戶數據量平時爲20個，特殊狀況下，每秒爲10萬，那麼測試環境要保證正常狀況下在20個左右，至少是十的數量級，性能測試特殊狀況下，要準備十萬級的數據量，模擬最高併發用戶數據量。

1.2.2高峯業務PV量

     1) 二八法

若80%的訪問量集中在20%的時間裏，可用此分析方法，其圖形就是一個正態分佈圖，以下。

具體計算公式爲：

     tps = (24小時的PV值*80%)/（24*3600*20%）

舉例有，假如中文站每日的訪問量爲500萬，其中19:00-23：40，訪問量爲400萬，其他時間段的訪問量很平坦，並且其他時間段的總訪問量爲100萬，那麼就能夠用二八法，其計算公式爲 tps = (500萬*0.8)/(24*3600*0.2)。

     2）簡單峯值法

若在天天的某一時段裏有很大的訪問量，其餘時間相對較少，能夠用簡單峯值法，其實二八法只是簡單峯值法的一個特例。

      具體計算公式爲：

        tps =(24小時的PV值)/（峯值時間段中的小時數*3600）

       舉例有，假如中文站每日的訪問量爲500萬，其中17:00-24:00這個時間段裏面訪問量爲450萬，其餘時間段的訪問量很平緩，那麼，我能夠用簡單峯值法近似計算，其計算公式爲 tps = 500萬/（（24-17）*3600）

 3）無峯值法

若24小時裏的訪問量都是平穩波動的，沒有峯值，那麼能夠採用無峯值計算方法，圖形以下。

       具體計算公式爲：

         tps= (24小時的PV值)/（24*3600）

        舉例有，假如中文站每日的訪問量爲500萬，每小時的訪問量都爲20萬左右，那麼，能夠用無峯值法來近似計算，其計算公式爲 tps = 500萬/(24*3600)。   

1.2.3吞吐量

      指軟件系統在每單位時間內能處理多少事務/請求/單位數據等，

其與tps的近似計算公式爲：（單位爲秒）

       tps = 這段時間內的總樣本數/（最後一個請求完成的時刻-第一個請求發起的時刻）

能夠這樣舉例，假如，在17：58的0 秒發起第一個請求，在18:02分0秒完成最後一個請求，在這4分鐘整的期間，共處理的總的樣本數爲1000個，那麼，能夠這樣近似計算：

                 tps = 1000/（4*60）

 值得注意的是，由於每一個請求之間的空閒值也包含在內了，故tps是有偏差的，並且tps是個平均值。

 

1、 性能測試需求分析

需求收集以後，咱們已經從性能需求文檔中提取出了業務性能測試指標，主要包括PV到TPS的轉換以及響應時間要求，接下來咱們須要進行進一步的需求分析過程。

1瞭解系統架構、明確壓力流向

    例如統一訂購平臺的系統架構圖：

 

理解架構圖中各個節點的功能與交互關係，經過系統架構圖咱們能看到壓力的入口，即oop應用。請求從oop發起，從udb取到會員數據後，經過dubbo接口，調用訂購服務層提供的各類服務，訂購服務層所需數據所有從對應cache中取。所以，主幹壓力流向可得知：

Oop—>udb

Oop—>dubbo—>訂購服務層—>cache

而後結合需求文檔，根據具體業務場景，肯定各分支壓力流向，好比有的業務場景須要從pc2取得用戶的服務記錄，有的業務場景須要付款則須要去賬戶中心取得賬戶信息，則新增的壓力流向以下：

Oop—>dubbo—>pc2—>cache

Oop—>dubbo—>賬戶中心

針對每個測試場景，都要根據系統架構圖進行上述分析，明確了各場景的壓力流向，即明確了性能測試過程當中的監控對象。

監控對象肯定後，須要進一步分析明確測試重點，如上例，咱們關注的重點是網站的oop應用，由於平臺的udb、pc2，crm的服務訂購中心，都有各自作過接口性能測試。或者有的所用應用功能是線上已有的，並無修改變更，如賬戶中心。明確測試重點，將有助於咱們進行測試環境相關的測試策略的選擇。

2 明確測試環境

2.1 服務器數量肯定

根據系統架構圖，咱們獲得了項目中所涉及的環境。衆所周知，測試環境越接近生產環境，則測試結果越精確。但一般咱們會碰到服務器資源緊張，或者所用應用爲外部門的外圍環境，搭建方法複雜。此時咱們面臨兩種選擇，要麼使用功能環境，要麼mock掉該環境。建議不要選擇前者，能夠多個壓力流向小的應用公用一臺性能服務器。

2.2 服務器配置肯定

仍是一條不變的原則：測試環境軟硬件配置儘可能與生產環境保持一致。

機器的性能需求：32位or64位；4核or8核；是否要求同一網段

    測試環境軟件架構肯定（jdk、apache、jboss版本、jvm參數）：與線上環境一致，重點關注jvm參數配置，確保與線上一致。

性能測試關注的主要硬件配置及OS參數以下表：

主機/ip	硬件配置		操做系統及參數調整
10.20.133.165 統一訂購層應用服務器	機型	PowerEdge 1950	Linux  2.6.18-92.el5 64位操做系統
	CPU	Intel(R) Xeon(R) CPU  E5410  @ 2.33GHz * 8
	內存	10G
	網絡	1000M

應用服務器配置檢查中經常使用的linux指令：

查看機型: dmidecode --type 1|grep "Product Name"

 

查看CPU: cat /proc/cpuinfo

 

查看內存：free -mt

 

紅框內即爲本機內存總量

查看網卡：

1）ifconfig 檢查服務器鏈接的哪塊網卡（ethx）

 

上圖紅框內即爲當前活動的網卡

2）ethtool ethx 檢查網卡詳細信息（ethx爲ifconfig檢查出來的網卡編號，如上圖就爲eth0）

 

上圖紅框內即爲當前網卡帶寬（雙工模式）

查看操做系統：

uanme -a 查看全部信息

uname -o, --operating-system    GNU/Linux

      -r, --kernel-release      2.6.18-128.el5（操做系統內核版本）

      -i, --hardware-platform   x86_64（硬件版本）

      -o, --operating-system    x86_64（操做系統版本）

3      關鍵業務數據量分析

3.1 數據量需求確認

1) 數據量是指的性能測試須要考慮的數據總量和數據類型。

例如在offer數據量爲30w的DB中查詢和在offer數據量爲1000w的DB中查詢，性能表現必定是不同的。咱們須要考慮，現階段的數據量等級和將來發展趨勢下的數據量等級。有的時候數據量也是程序分支邏輯，因此這點就必須詳細考慮了。

2)    存儲分佈指的數據源的分佈狀況，是分佈式分佈仍是單臺分佈；是search分佈仍是DB分佈，等等。例如offer拆分項目的性能測試就須要綜合考慮Oracle單表、Oracle16張表、mysql128張表的使用場景

3)    基本要求：測試數據庫數據量要與線上數據量保持一個數量級。

3.2 造數據方法肯定

根據數量級的須要，能夠採用不一樣的方法，大體有如下幾種：

1） 找DBA幫忙導線上/測試庫數據；

2） 用datafactory/sql直接插數據庫；（查看datafactory文檔）

界面如圖，具體使用方法問google

 

3） 用jmeter/LR/ruby等腳本走正常業務流造數據。（查看各腳本錄製方法）

3.3劃分測試場景、明確測試用例

測試用例的產生須要考慮如下幾方面：

1)    測試頁面和業務邏輯，也就是業務對應的功能點

注意，性能測試的測試用例也須要專注性，也就是對應單個測試功能點。

由於咱們監控的是每一個事物的響應時間，功能點須要單一。

2)    壓力持續時間

壓力持續時間指的是給服務器施加多長時間的壓力。

這個時間，咱們會結合測試場景，對壓力時間作必定的控制。

ü  若是測試的是高峯場景，時間通常最少爲1個小時；

ü  若是測試的是穩定性場景，時間通常最少要求8小時；

3)    併發數

不要混淆併發和TPS的關係。

併發數指的是同時有多少用戶（線程）在對服務器施加壓力，是量化的給服務器的壓力；而TPS指的是服務器每秒鐘可以處理的事物數，是服務器處理能力的體現。