Home | 簡體中文 | 繁體中文 | 雜文 | 打賞(Donations) | 雲棲社區 | OSChina 博客 | Facebook | Linkedin | 知乎專欄 | Github | Search | About

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

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

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

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

16.2.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,緩存,資料庫等等伺服器,都需要逐一優化到最佳狀態

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

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

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

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

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

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

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

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

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

  1. 運維部門

  2. 開發部門

  3. 測試部門

16.2.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 手札》