最近學習瞭如何做壓力測試,所以這裡總結一下壓力測試所需要的工具、如何選擇壓力測試的參考對象和目標對象,還有如何提取壓力測試結果的重要信息,最後依據這些信息選擇不同的優化方案

什麼是壓力測試

壓力測試是模擬實際應用的軟硬體環境及用戶使用過程的系統負荷,長時間或超大負荷地運行測試應用,來測試被測系統的性能、可靠性、穩定性等。

壓力測試的意義

壓力測試的結果包括單位時間響應次數、平均響應時間,最長響應時間和最短響應時間等數據,這些數據能作為如何優化項目重要的參考依據。

壓力測試工具

Siege

  • 基本用法: siege -c100 -t1 -b http://localhost:3000,測試指定url,可以獲取到該url的壓測結果
  • 參數解釋:
    • -c表示並發數,
    • -t表示壓測時間,
    • 更多參數解釋可以訪問 joedog.org/siege-manual

  • 輸出結果

  • 結果中的關鍵數據是
    • Transaction rate,這代表Request per second,這個數字越高,表示伺服器的每秒處理能力越高
    • Failed transactions,如果出現非0數字,表示伺服器開始出現無法響應的情況

壓力測試的對象選擇

參考對象

  1. 一個靜態頁面的url目的是為了測試os server+http server,目標對象的測試結果越接近這個的測試結果是最理想的。在rails項目中就是放在public目錄下的靜態頁面。
  2. 一個簡單不帶複雜業務邏輯的、也不帶資料庫查詢的app頁面的url,目的是為了測試os server+http server+app server ,優化結果越接近這個的測試結果越好。在rails項目中就是,需要Rails路由匹配且不帶layout的靜態頁面

參考對象1 可以選擇404頁面。符合 參考對象2 的頁面一般是不存在的,因為這樣的頁面通常都會被放在public目錄下,所以需要特意創建一個這樣的頁面。

目標對象

  1. 靜態路由:如首頁(localhost:3000)、About頁面(localhost:3000/about)
  2. 動態路由:如文章詳細頁面(localhost:3000/articles/:id)

目標對象的平均響應時間越接近 參考對象1代表頁面的優化程度越高。

壓力測試結果分析

測試樣例

benchmarking result@2016-06-29 15:00:56 +0800

  • concurrence: 100
  • times: 3min

benchmarking result@2016-06-29 16:05:38 +0800

  • concurrence: 200
  • times: 3min

benchmarking result@2016-06-29 11:18:09 +0800

  • concurrence: 300
  • times: 3min

benchmarking result@2016-06-29 16:44:50 +0800

  • concurrence: 400
  • times: 3min

結果分析

  • 極限響應並發數:300

極限並發數是項目平均響應時間最短的頁面能穩定響應請求的並發數,它的值可取 參考對象1在測試中出現Failed佔比低於0.1%的最大並發數。

  • Web server的RPS:152

Web server的RPS是項目在極限響應並發數下Web server每秒能處理的請求數,它的值取自測試樣例的 html page 在Trans rate列的值

  • App server的RPS:30

App server的RPS是項目在極限響應並發數下App server每秒處理的請求數,由於測試樣例中存在多個App server page,所以這裡取測試樣例中app server page中Trans rate最低的一個,這個例子裏的是 article_detail_page 的Trans rate 約30

  • 項目可支持每日訪問量範圍:1728000 ~ 13132800

項目可支持每日訪問量範圍的下限是App server的RPS的值乘以16小時(假設常規用戶是從早上8:00到晚上12點在線)的秒數,項目可支持每日訪問量範圍的上限是Web server的RPS的值乘以24小時的秒數,可以得出項目可支持每日訪問量範圍是 1728000(30 * 16 * 60 * 60) ~ 13132800 (152 * 24 * 60 * 60)

優化方案

根據壓力測試的結果給出優化建議是壓力測試的意義所在。以下列出一些壓測的結果和通常情況下相應的優化方案,具體還要視項目的具體情況選擇優化方案。

  1. 目標對象的頁面內容不需要即時更新。這種情況可以使用page caching,並使用cornjob設置定時清除緩存命令。
  2. 目標對象是一個很少改動,但改動後頁面內容需要即時更新。這種情況可以使用action caching,並且在相關內容修改後清除緩存。
  3. 目標對象經常改動,並且改動後頁面內容需要即時更新的。這種情況可以使用fragment caching,這是最簡單的緩存策略,不需要配置緩存失效的操作
  4. 項目預期訪問並發的峯值大於極限可響應並發數。這種情況就不能從代碼上解決問題了,而是需要升級伺服器,搭建負載均衡等從伺服器方面入手的方案

推薦閱讀:

相關文章