性能測試---實戰篇

1、性能測試的目的

• 目的在於測試系統相關性能能否滿足業務需求。
• 找各種bug，找bug的途徑如下
  • 高壓力
  • 長時間
  • 與功能測試的區別在於量的不同
• bug的表現
  • 系統掛掉
  • 系統性能持續快速下降/周期性變化
  • 系統響應緩慢且壓力下降后沒有恢復
  • …………

2、需求分析

• 測試對象
  • 要測啥？
  • 有沒有必要測？
  • 通常，可以從以下幾個方面考慮：
    • 是否核心功能，是否要求嚴格的質量
    • 是否常用、高頻使用的功能
    • 可能占用系統較多資源的功能
    • 使用人數多還是少
    • 在線人數多還是少
• 拆分對象
  • 先從業務上來分，實現這個完整的功能包含哪些流程、環節
  • 比如：購買商品
    • 登錄->搜索商品->提交訂單->支付訂單->退出
  • 然后從功能實現上來看，怎么實現這個完整功能的。通常這些業務功能操作都對應着一個或多個請求(可能能是不同類型的請求，比如 http, mysql 等)，我們要做的是找出這些操作對應的請求，請求之間的順序是怎么樣的。
• 指標分析
  • 分析性能需求指標（如“支持 300 人並發登錄”）是否合理
  • 有沒有必要測試這個需求，考慮需求指標是否合理？有沒有數據支撐？
  • 通常，支撐數據可以從以下方面考慮：
    • 采樣時間段內系統使用人數
    • 采樣時間段內系統在線人數
    • 采樣時間段內系統(頁面)訪問量
    • 采樣時間段內請求數
    • …………
  • 常用分析思路：
    1. 2/8 法則
       • 2/8 法則：80%的業務量在 20%的時間里完成。這里，業務量泛指訪問量，請求數，數據量等
    2. 正態分布
    3. 按比例倍增
    4. 響應時間 2-5-8
       • 就是說，一般情況下，當用戶能夠在 2 秒以內得到響應時，會感覺系統的響應很快；當用戶在 2-5 秒之間得到響應時，會感覺系統的響應速度還可以；當用戶在 5-8 秒以內得到響應時，會感覺系統的速度很慢，但是還可以接受；而當用戶在超過 8 秒后仍然無法得到響應時，會感覺系統糟糕透了，或者認為系統已經失去響應。
    • 注意：這個要根據實際情況，有些情況下時間長點也是可以接受的，比如購票網站
    • 舉例：
      • 某公司后台監控，根據一段時間的采樣數據，分析得出日高峰時段(11:00-14:00)用戶下單請求數平均為1000，峰值為 1500，根據這個計算並發請求數。
      • 時段：3 個小時 -> 3 x 60 x 60 = 1080s
      • 業務量：1500
      • 吞吐量：1500 * 80% / (1080 * 20%) = 5.56 請求數/s
    • 注意:
      • 2/8 原則計算的結果並非在線並發用戶數，是系統要達到的處理能力（吞吐量）
      • 如果要求更高系統性能，根據實際情況，也可以考慮 1/9 原則或其它更嚴格的算法
      • 以上估值只是大致的估算，不是精確值
  • 數據生命周期：
    • 一般來說，數據都是有一定的生命周期的，時間的選取需要結合數據周期考慮。這里假設 3 年后系統性能仍然需要滿足業務需求。
  • 數據增長率：
    • 如果是老項目，可以考慮對應功能主表歷史數據存放情況
    • 這里假設按年統計，比如第一年 10000，第二年 15000，第三年 20000，第四年 25000，那么我們得出，以第一年為基准，數據增長率分別為 0.5，1，1.5，每年在上一年的基礎上，以 5000 的速度增長。預估 3 年后，數據增長率為 3，需要測試數據量為 （1+3）x 10000 = 40000
    • 注意：
      • 實際數據一般是沒上面舉例那么規律的，只能大致估算數據增長率。
      • 一些大數據量的性能測試除了和數據量相關，還涉及到數據分布等，比如查詢，構造數據時需要結合實際，盡量貼近實際。
      • 不同業務模塊，涉及表不一樣，數據量要求也是不一樣的，需要有區別的對待。
    • 如果是新項目，那就比較不確定了，除非能收集相關數據。

3、理發店模型

• 一個理發店有三位理發師傅
• 每位理發師傅服務一位顧客需要一小時
• 顧客從進理發店起最多只能等待三小時

---

理發區
|h| |h| |h|
|_| |_| |_|

等待區                    紅色報警區
|w| |w| |w| |w| |w| |w| |w| |w| |w|
|_| |_| |_| |_| |_| |_| |_| |_| |_|

• 最佳用戶數:3
• 最大用戶數:9
• web模型

---

|-------------------------tomcat -------------------------|--------- nginx ----------|
|----------處理中-------------|----------排隊中-------------|---------排隊中------------|

• 沒有排隊的server
  • pop3,imap,smtp

---

|-------------------------server ------------------------| |--------- client ----------|
|------------------------處理中---------------------------| |-----------等待中-----------|

4、系統分析

• 結合需求分析，分析系統架構。
  1. 請求順序、請求之間相互調用關系
  2. 數據流向，數據是怎么走的，經過哪些組件、服務器等
  3. 預測可能存在性能瓶頸的環節（組件、服務器等）
  4. 明確應用類型 IO 型，還是 CPU 消耗性、抑或是內存消耗型 -> 弄清楚重點監控對象
  5. 關注應用是否采用多進程、多線程架構 -> 多線程容易造成線程死鎖、數據庫死鎖，數據不一致等
  6. 是否使用集群/是否使用負載均衡
• 通常建議測試時先不考慮集群，采用單機測試，測試通過后再考慮使用集群，這樣有個比較，比較能說明問題。

5、業務分析

• 明確要測試的功能業務中，功能業務占比，重要程度。目的在於
  • 明確重點測試對象，安排測試優先級
  • 建模，混合場景中，虛擬用戶資源分配，針對不同業務功能施加不同的負載。
• 明確下“需求分析-指標分析”中相關業務功能所需基礎數據及數據量問題，因為那塊需求分析時可能
  只是大致估算下，評估指標是否合理，需要認真再分析下

6、用例設計

• 系統業務特點和用戶行為分析-- 測試對象
• 系統性能指標分析-- 測試目標
• 性能測試執行策略分析-- 測試執行

用例設計--系統業務特點和用戶行為分析

• 使用高峰時段分析
• 高峰期業務應用分析
• 高峰時段統計方法
  • 按時間進行分類
    • 工作日，節假日
    • 每日的上班時間，下班時間
  • 統計粒度建議1小時
• 業務分析統計方法
  • 統計特定時間段業務調用次數
  • 按倒序排列
  • 計算各業務數量占比
• 如無真實環境
  • 使用類似功能的其他環境統計

用例設計--系統性能指標分析

• 並發用戶數量設計
  • 按既定目標設計
  • 逐步提升數量，找到合適的數量
• 事務平均響應時間--3，5，8秒（具體看實際情況而定）
  • 3秒以內用戶會認為響應時間較快；
  • 5秒以內用戶認為可以接受；
  • 超過8秒，一般用戶會認為響應太慢

用例設計--性能測試執行策略分析

• 單業務測試
  • 核心模塊對應的業務
  • 頻繁使用的業務
• 混合業務測試
  • 按比例組合各個單業務進行測試

事務定義

• 根據用例合理的定義事務，方便分析耗時（特別是混合業務功能場景測試），進而方便分析瓶頸。
  比如，購買商品，我們可以把下訂單定義為一個事務，把支付也定義為一個事務。

場景監控對象

• 針對每條用例，結合“系統分析”第 4）點，明確可能的壓力點（比如數據庫、WEB 服務器），需要監控的對象，比如 tps，耗時，CPU，內存，I/O 等。

7、測試策略

1. 先進行混合業務功能場景的測試，再考慮進行測試單業務功能場景的測試
2. 負載測試 -> 壓力測試-> 穩定性測試-> 強度測試
3. 逐步加壓
   • 比如開始前 5 分鍾，20 個用戶，然后每隔 5 分鍾，增加 20 個用戶。
   • 好處：不僅比較真實的模擬現實環境，而且在性能指標比較模糊，且不知道服務器處理能力的情況下，可以幫我們確定一個大致基准，因為通常情況下，隨着用戶數的不斷增加，服務器壓力也會隨着增加，如果服務器不夠強大，那么就會出現不能及時處理請求、處理請求失敗的情況下，對應的運行結果圖形中，運行曲線也會出現對應的形態，比如從原本程一條穩定直線的情況，到突然極限下降、開始上下波動等，通過分析我們就能得出服務器大致處理能力，供后續測試參考。
4. 單點並發
   • 比如使用集合點，單獨針對某個環節的並發測試，通常是針對某個環節的性能調優時使用。

• 常識：
  • 負載測試
    • 保證系統能正常運行(通常是滿足某些系統性能指標)的前提下，讓被測對象承擔不同的工作量，以評估被測對象的最佳處理能力、最大處理能力以及存在缺陷而進行的測試。
  • 壓力測試
    • 不保證系統能否正常運行的前提下，讓被測對象承擔不同工作量，以評估被測對象能提供的最大處理能力及存在的缺陷而進行的測試，方便知曉系統響應何時退化和失敗。
  • 穩定性測試
    • 測試系統的長期穩定運行的能力。同疲勞強度測試的區別是，穩定性測試的壓力強度較小，一般趨向於客戶現場日常狀態下的壓力強度，當然在通過時間不能保證穩定性的狀態下，需要加大壓力強度來測試，此時的壓力強度則會高於正常值。
  • 強度測試
    • 通常模擬系統在較差、異常資源配置下運行，如人為降低系統工作環境所需要的資源，如網絡帶寬，系統內存，數據鎖等等，以評估被測對象在資源不足的情況下的工作狀態。
    • 注：疲勞強度測試是一類特殊的強度測試，主要測試系統長時間運行后的性能表現，例如 7x24 小時的壓力測試。

8、各種指標

各種指標--系統性能指標

• TPS（Transaction per Second）
  • 系統每秒處理交易數，單位是筆/秒。越大越好 ↗
• VU（Virtual User）
  • 虛擬用戶，並發數。
• RT（Response Time）
  • 交易響應時間，低於5秒。越小越好↘
• FR（Failure Ratio）
  • 錯誤率，低於 6‰。越小越好↘
• 90%響應時間
  • 有90%的事務的響應時間低於此。越小越好↘

各種指標--硬件性能指標

• CPU占用

  • user
  • sys
  • wait
  • 如果 CPU 有 100％ 利用率，那么應該到達這樣一個平衡：65％－70％ User Time，30％－35％ System Time，0％－5％ Idle Time（僅供參考）。
  • 如果User值大於 80%，說明可能存在CPU資源不足。
  • 上下文切換應該和 CPU 利用率聯系起來看
    • 比如system time（sy）很高，而 user time（us）很低，而且加上高頻度的上下文切換（cs），則說明正在運行的應用程序調用了大量的系統調用（system call）
    • user time（us）一直保持在 80％ 以上，而且上下文切換較低（cs），則說明某個進程可能一直霸占着 CPU。
  • 可運行隊列 run queue（r），每個可運行隊列不應該有超過1－3個線程（每處理器，即每個核數），比如：雙處理器系統（單CPU的雙核系統）的可運行隊列里不應該超過6個線程。

• 磁盤

  • 占用：nmon中的 Disk Busy，iostat中的 %util（表示磁盤忙碌情況）
    • 如%util接近100%，表示磁盤產生的I/O請求太多，I/O系統已經滿負荷，該磁盤可能存在瓶頸。
  • TPS：nmon中的 DISKXFER ，iostat中的tps（即為磁盤的 IOPS）
    • tps：每秒向磁盤設備請求數據的次數（每秒從物理磁盤 I/O 的次數），包括讀、寫請求，為rtps與wtps的和。出於效率考慮，每一次IO下發后並不是立即處理請求，而是將請求合並(merge)，這里tps指請求合並后的請求計數。
    • 在測試工作中，我們主要關注 IOPS 和吞吐量以及磁盤的 busy% 這三個數值。如果 IOPS 和吞吐量均很低，磁盤的 busy% 也很低，我們會認為磁盤壓力過小，造成吞吐量和 IOPS 過低；只有在 IOPS 和吞吐量均很低，磁盤的 busy% 很高（接近 100%）的時候，我們才會從磁盤 I/O 方面分析 I/O 性能，磁盤 I/O 可能存在瓶頸。

• 內存

  • 操作系統會最大化利用內存，利用率高並不是問題
  • 需要觀察是否有大量的swap

• 網絡

  • 可能有些有些環境是百兆網，存在帶寬不足
  • 可能受防火牆，負載均衡影響

各種指標--穩定性指標

• 最短穩定時間：系統按照最大容量的80%或標准壓力（系統的預期日常壓力）情況下運行，能夠穩定運行的最短時間。
  • 對於正常工作日（8小時）運行的系統，至少應該能保證系統穩定運行８小時以上。
  • 對於7*24運行的系統，至少應該能夠保證系統穩定運行24小時以上。如果系統不能穩定的運行，上線后，隨着業務量的增長和長時間運行，將會出現性能下降甚至崩潰的風險。
• TPS曲線穩定，沒有大幅度的波動。
  • 需要排除系統定時任務造成的波動
• 各項資源指標沒有泄露或異常情況。

各種指標--瓶頸，分析

• 木桶原理
  • 一只木桶盛水的多少，不取決於桶壁上最高的那塊木塊，而恰恰取決於桶壁上最短的那塊
  • 推論一
    • 只有桶壁上的所有木板都足夠高，那木桶才能盛滿水
  • 推論二
    • 只要這個木桶里有一塊不夠高度，木桶里的水就不可能是滿的。
• 觀察硬件指標中哪個滿載，哪個就是瓶頸
  • cpu 100%
  • 磁盤占用（DISK busy 100%）
  • 網絡帶寬滿了
  • 大量使用swap時，可能是內存不夠
• 如果所有資源都很空閑
  • 可以進一步提升壓力
  • 程序需要優化
• 系統性能表現應該與壓力相符
  • 正常的表現
    • 壓力上升，TPS，CPU，磁盤同時上升
    • 壓力平穩，曲線平穩
    • GC表現正常
  • 不正常的表現
    • 壓力平穩， 內存占用持續增長， CPU持續增長
    • 壓力上升，CPU下降
    • 壓力不大，但GC表現不正常，如頻繁full GC

9、並發數 vs TPS

• 衡量系統性能的兩種標准

  • 用戶角度：系統支持xxx並發用戶
  • 服務器端角度：系統每秒處理xxx個事務

• 相互換算

  • TPS=VU / RT

• 通過TPS估算VU

  • 最大VU：TPS*5S
  • 最佳VU：TPS*3S
  • 例外：
    • VU超過系統最大線程數+等候隊列數
    • SMTP，POP3，IMAP沒有排隊機制
    • nginx配置了max_conns

• 例子

  • 系統a支持5000並發用戶
  • 系統b支持3000並發用戶
  • 系統a的RT=2秒
  • 系統b的RT=1秒
  • 系統a的TPS=2500
  • 系統b的TPS=3000

• 系統的性能由TPS決定，跟並發用戶數沒有多大關系。

• 系統的最大TPS是一定的（在一個范圍內），但並發用戶數不一定，可以調整。（與響應時間有關）

• 混合場景中如何實現各業務按指定比例運行?

  • 並發數比例 ≠ TPS比例
    • 不同事務的響應時間不一樣
  • 日志統計需要區分並發數與TPS
  • 用vu的比例來模擬TPS的比例比較困難
  • 可采用JMeter函數助手中的__counter函數實現

10、基准/版本測試

• 基准測試是指通過設計科學的測試方法、測試工具和測試系統，實現對一類測試對象的某項性能指標進行定量的和可對比的測試。
• 有一套固定硬件，一套測試場景
• 在此固定硬件上按測試場景進行測試，並記錄測試結果
  • 以此結果作為系統在此硬件上的參考性能
• 用途
  • 不同版本系統性能參考
  • 配置相似的硬件的性能參考
• 比較原則
  • 盡可能減少變更內容，減少干擾項
    • 如：軟硬件只改變一個
• 與上一版本的性能對比
• 本版本的穩定性
• 不同硬件的性能估算
  • 木桶原理
    • 增加非瓶頸性能並不會提高整體性能
    • 只有提升瓶頸性能才能提升系統性能
  • CPU是瓶頸
    • CPU處理器個數與性能大致上是線性關系
  • IO是瓶頸
    • 與實際的IO性能IOPS有關系，但未知是否線性
  • 內存
    • 一般只有容量夠和不夠的區別，內存速度一般不成為瓶頸

11、統計學相關

• 統計學相關--x%平均響應時間
  • 通常取90%作為整體的參考時間
• 統計學相關--曲線平穩

  • 變異系數，又稱“離散系數”（coefficient of variation），是概率分布離散程度的一個歸一化量度，其定義為標准差與平均值之比

      變異系數 C·V = 標准差 SD / 平均值Mean 
    

• 統計學相關--排隊論
  • 排隊論(Queuing Theory) ，是研究系統隨機聚散現象和隨機服務系統工作過程的數學理論和方法，又稱隨機服務系統理論，為運籌學的一個分支。
  • 單位時間訪問服務器的用戶數服從泊松分布，其概率密度函數可百度查看
  • excel 公式：POISSON(x,mean,cumulative)
  • POISSON 函數語法具有下列參數：
    • X 必需。 事件數。
    • Mean 必需。 期望值。
    • cumulative 必需。 一邏輯值，確定所返回的概率分布的形式。 如果 cumulative 為 TRUE，則 POISSON 返回發生的隨機事件數在零（含零）和 x（含 x）之間的累積泊松概率；如果為 FALSE，則 POISSON 返回發生的事件數正好是 x 的泊松概率密度函數。