Home | 簡體中文 | 繁體中文 | 雜文 | 知乎專欄 | Github | OSChina 博客 | 雲社區 | 雲棲社區 | Facebook | Linkedin | 視頻教程 | 打賞(Donations) | About
知乎專欄多維度架構 微信號 netkiller-ebook | QQ群:128659835 請註明“讀者”

第 20 章 多維度架構之壓力測試

目錄

20.1. 壓力測試中存在的問題
20.1.1. (What) 什麼是壓力測試
20.1.1.1. 壓力測試存在哪些問題
20.1.2. (Why) 為什麼做壓力測試
20.1.3. (Where) 在哪裡做壓力測試
20.1.4. (When) 什麼時間做壓力測試
20.1.5. (Who) 壓力測試過程參與人員
20.1.6. (How) 如何做壓力測試
20.2. 協議測試
20.2.1. What 什麼是協議測試
20.2.2. Why 為什麼要做協議測試
20.2.3. where 在哪兒測試
20.2.4. when 什麼時候測試
20.2.5. Who 誰來做,執行對象
20.2.6. How 怎樣做測試
20.2.7. 如何學習協議測試
20.2.8. 總結
20.3. 打破軟件自動化測試的格局
20.3.1. 自動化測試的誤區
20.3.2. 分層與部署帶來的問題
20.3.3. 壓力測試存在的問題
20.3.3.1. 壓力測試環境
20.3.3.2. 測試順序
20.3.3.3. 瓶頸分析
20.3.3.4. 指導開發
20.3.4. 持續整合形同虛設
20.3.5. 測試的終極目標

20.1. 壓力測試中存在的問題

20.1.1. (What) 什麼是壓力測試

軟件壓力測試是一種基本的質量保證行為,它是每個重要軟件測試工作的一部分。軟件壓力測試的基本思路很簡單: 不是在常規條件下運行手動或自動測試,而是在計算機數量較少或系統資源匱乏的條件下運行測試。 通常要進行軟件壓力測試的資源包括內部內存、CPU 可用性、磁碟空間和網絡頻寬。

壓力測試涵蓋,性能測試,負載測試,並發測試等等,這些測試點常常交織耦合在一起。

20.1.1.1. 壓力測試存在哪些問題

我歸納一下有幾點:

  1. 操作系統預設安裝,在未做任何優化的情況下實施壓力測試

  2. 未考慮磁碟IO對軟件的影響

  3. 未考慮網絡頻寬對軟件的影響

  4. 網絡軟件測試,沒有考慮到TCP特點

  5. 各種超時參數優化

  6. 測試客戶端未優化

  7. 並發理解有誤

  8. WEB伺服器,資料庫,等等伺服器未優化

如果上面幾項沒有做優化,壓力測試數據基本沒有任何參考價值,任何一項沒有優化,都會導致你的壓力測試數據出現偏差。 下面我來逐條說明:

  1. 操作系統問題: 操作系統是大眾化軟件,出廠優化都是面向大眾,不可能為某個領域做單獨優化。所以我們第一步需要優化操作系統。 Linux 系統優化內核參數,Windows 系統優化註冊表等等。

  2. 磁碟IO: 這是最容易出現瓶頸的地方,常常是CPU還沒有達到極限,磁碟已經不堪重負。

  3. 網絡IO: 與磁碟IO相同

  4. TCP連接: 几乎所有 B/S, C/S 軟件都是採用多綫程,或者多進程技術。這種技術有個特點,開發者將程序設計為綫程可自動伸縮模式,開啟進程後會啟動少量綫程,當連接不斷提高後,綫程數逐漸增加,隨着綫程運行結束後,綫程逐漸減少。 這樣的設計會更有效地利用硬件資源,在程序空閒時將硬件資源讓給其他進程。少有軟件設計為開啟服務獨占資源。 這樣測試軟件做壓力測試,不能一次並發很多請求,而是要採用逐漸增加的方式,否則第一次測試會有一部分並發不能及時響應,導致測試數據偏差。另外也你可以多做幾次壓力請求(讓多綫程工作起來),從第三次開始記錄測試數據,忽略前面兩次的測試數據。

提示:另一個問題是TCP連接復用,這也是一個重要配置項。如果這項沒有配置,我想測試出的數據也會有偏差

  1. 超時參數: 超時參數在壓力測試中是非常重要的參數,例如從WEB到資料庫連接超時是60秒,如果有一個SQL查詢超過300秒,那麼後面的請求會持續排隊等待,當連接數達到資料庫的最大連接時,接下來的所有請求都是失敗的。 通常我們的WEB伺服器超時不會超過30秒,有時我設置為10秒,一旦出現超時,寧可讓該連接Timeout,不要讓他影響整體服務。

  2. 客戶端: 很多網絡軟件需要從客戶端發出壓力測試請求,所以客戶端的優化也是必須的,否則客戶端壓力出不去,服務端壓力進不來。

  3. 並發: 很多人認為並發,就是同一時間內的最大連接數,這是錯誤的。如果你寫過多綫程程序,就會發現多綫程運行時有規律的。是順序排隊運行的,根本不是同時運行的。 所以並發是指,相對時間內能完成的連接總和,例如,每秒並發,每分鐘並發等等,通常我們已秒為單位。 我們目前使用的操作系統叫分時操作系統,這種系統的特點就是可能實現多用戶,多任務。操作系統將進程排隊(優先順序)輪詢運行,只不過這個操作太快了,使你認為多個進程在同時運行。

  4. 伺服器優化: 主要B/S軟件壓力測試,WEB,緩存,資料庫等等伺服器,都需要逐一優化到最佳狀態

20.1.2. (Why) 為什麼做壓力測試

如果在軟件設計階段都將這些問題元素都考慮進去,同時開發階段嚴格執行。那麼開發出些軟件几乎不用做這個勞人傷神的壓力測試。

所以在軟件設計階段就要考慮,靈活性,擴展性,可靠性與性能,還要考慮高可用與負載均衡。

同時軟件優化伴隨開發,持續整合,持續測試,持續部署。

20.1.3. (Where) 在哪裡做壓力測試

有些軟件需要封閉的環境測試,不能在共享資源的環境中做測試。所以你有必要做Vlan隔離,甚至獨立的路由器與交換機在封閉網絡中測試。

20.1.4. (When) 什麼時間做壓力測試

任何時間都可能做壓力測試,為什麼我將“時間”重點提出呢?目前受地球自轉影響,經常閏秒,你不的不考慮這個問題。

20.1.5. (Who) 壓力測試過程參與人員

  1. 運維部門

  2. 開發部門

  3. 測試部門

20.1.6. (How) 如何做壓力測試

下面我們舉一些例子,講述壓力測試方法,限于篇幅不可能面面俱到,我僅僅是給你提供思路。

測試前你需要一些監控工具,實時監控伺服器的資源變化。

例如 Web 伺服器壓力測試,測試場景是 nginx :

    
    worker_processes  8;            處理器數
    worker_rlimit_nofile 65530;     允許最多打開檔案數
    worker_connections  4096;       最大連接數數為
    keepalive_timeout  65;          開啟復用連接
    gzip  on;                       壓縮傳輸數據
    
			

怎麼測試呢?你要獲得最大化性能嗎?還是相對性能?我們通常需要的是滿足需求就好的相對性能,而不是最大化性能。為什麼呢?因為要獲得最大化性能是要做出很多配置犧牲的,例如關閉日誌,禁止訪問時間等等。

按照上面的配置你的測試用例應該是,每次並發4000 請求 8000~10000 次, 你不能並發8000 請求 4000 這樣測試。很是很多人常常犯的錯誤,所以測試者需要連接系統的配置參數,不能盲目使用數字實驗。

上面我說過綫程的開啟時隨着請求,逐漸增加的,所以首次發起測試數據是不准確的,通過pstree命令可以看到綫程數量。等第三次以後綫程逐漸增加到4096個,並且之前開啟的TCP可以復用,這時測試的結果比較有說服力。

延伸閲讀《Netkiller Web 手札》《Netkiller Testing 手札》《Netkiller Linux 手札》