關於性能測試的幾個要點

時間 2019-11-07

標籤關於性能測試幾個要點欄目系統性能简体版

原文原文鏈接

幾個定義

性能測試（Performance Test）

一般收集全部和測試有關的全部性能，一般被不一樣人在不一樣場合下進行使用。測試軟件在系統中的運行性能，度量系統與預約義目標的差距。html

關注點：how much和how fastlinux

負載測試（Load Test）

負載測試是一種性能測試，指數據在超負荷環境中運行，程序是否可以承擔。經過逐步增長系統負載，肯定在知足性能指標的狀況下，系統所能承受的最大負載量。git

關注點：how muchgithub

壓力測試（Stress Test）

壓力測試是一種高負載下的負載測試，也就是說被系統處於一個負載的狀況，再繼續對他進行加壓，造成雙重負載，知道系統崩潰，並關注崩潰後系統的恢復能力，之前再加壓的一個過程，看看系統究竟是否已經被完全破壞掉了。web

有個很形象的說法就是：你可以承擔100千克的重量，並且也能走，可是你可否承擔100千克的重量行走1個月。apache

外部的負載叫壓力，內部的壓力叫負載。負載注重關注內部的以及系統自身一些狀況；而壓力更關注系統外部的表象.緩存

性能測試模型

性能測試的執行過程是由輕到重，逐漸對系統施壓。一般用戶最關心的性能指標包括：響應時間、吞吐量、資源利用率和最大用戶數。咱們能夠將這張圖分紅3個區域，即：輕負載區域、重負載區域和負載失效區域。服務器

輕負載區域
在這個區域您能夠看到隨着虛擬用戶數量的增長，系統資源利用率和吞吐量也隨之增長，而響應時間沒有特別明顯的變化；cookie
重負載區域
在這個區域您能夠發現隨着虛擬用戶數量的增長，系統資源利用率隨之緩慢增長，吞吐量開始也緩慢增長，隨着虛擬用戶數量的增加，資源利用率保持相對的穩定（知足系統資源利用率指標），吞吐量也基本保持平穩，後續則略有下降，但幅度不大，響應時間會有相對較大幅度的增加；網絡
負載失效區域
在這個區域系統資源利用率隨之增長並達到飽和，如CPU利用率達到95％甚至100%，並長時間保持該狀態，而吞吐量急劇降低和響應時間大幅度增加（即：出現拐點）。
兩個交界點
在輕負載區域和重負載區域交界處的用戶數，咱們稱爲"最佳用戶數"。而重負載區域和負載失效區域交界處的用戶數則稱爲"最大用戶數"。

當系統的負載等於最佳用戶數時，系統的總體效率最高，系統資源利用率適中，用戶請求可以獲得快速響應；

當系統負載處於最佳用戶數和最大用戶數之間時，系統能夠繼續工做，可是響應時間開始變長，系統資源利用率較高，並持續保持該狀態，若是負載一直持續，將最終會致使少許用戶沒法忍受而放棄；

而當系統負載大於最大用戶數時，將會致使較多用戶因沒法忍受超長的等待而放棄使用系統，有時甚至會出現系統崩潰，而沒法響應用戶請求的狀況發生。

併發用戶數

相對併發用戶數(`用戶視角`)

即線用戶數，在一個時間段內，與服務器進行了交互、對服務器產生了壓力的用戶的數量。這個時間段，能夠是一天，也能夠是一個小時。

一般像ab、wrk等併發工具設定的併發數，就是指的這個併發數，好比在JMeter中，若是將某個線程組的線程數設置爲100，那是否是對於這個類型的請求，併發量就是100。從宏觀的角度，這樣理解也是對的，就比如請了100我的，每一個人獨立地完成一連串的工做，確實是100個在並行。可是對於服務器感覺到的壓力，可能就不是100了。

這裏所謂的100個並行對於服務端而言並非嚴格的所有並行，由於每一個虛擬用戶執行的節奏是獨立。假設這個操做須要3個請求完成，那麼頗有可能出現這樣的狀況：某個虛擬用戶還在等待第一個請求的響應，可是另外一個虛擬用戶已經收到了第一個請求的響應併發起了第二個請求。那麼對於服務端而言，在某一個時刻，不管是對於請求1仍是請求2，並行度都沒有到100。這個模型比較相似於圖中右邊部分所示的模型。理解這個模型對於並行的理解很是重要。

這裏的差別在於宏觀上的並行仍是嚴格意義上的並行，好比就某個請求的嚴格意義上的並行或許能夠經過TCP鏈接的保持數來看。經過「netstat|grep ESTABLISH|wc-l」命令得到保持鏈接狀態的TCP請求數量。也就是下面的絕對併發用戶數。

併發與並行是相關的概念，可是也有不少細節上的差別。併發意味着兩個或更多的任務正在取得進展，即便它們不是同時執行的。例如，能夠用時間片的方式實現這一點，每一個任務在時間片內執行一小部分，並與其它任務的切片混合執行。如併發收集器。並行的出現使任務實現了真正的同時執行。

絕對併發用戶數(`服務器視角`)

主要是針對某一個操做進行測試，即多個用戶同一時刻發起相同請求。

圖中，每個顏色的線段表明一種操做。在任意一個時刻，服務器都知道它有10個事務須要處理，這10個事務也是有10個用戶產生的。但它不知道的是，整個時間段內的全部事務，是由多少個用戶與系統交互而產生的。時刻1，10個當前事務是由10個用戶發起的。時刻2，依然是10個正在進行的事務，但多是徹底不一樣的10我的發起的。在這段時間內，服務器每個時刻都在處理10個事務，可是參與了這個交互過程（對服務器產生壓力）的人可能會達到上百個，也可能只有最開始的10個。那麼，對於服務器來講，壓力是什麼呢？顯然只是每時刻這10個同時處理的事務。

Think Time

在進行相對併發用戶數的測算時，think time的設置會影響測試的結果。設想這樣的一個場景，一個真實的用戶在某個電商網站上購物，一個簡化的流程可能以下： 1）進入首頁 2）搜索一個商品 3）查看商品詳情 4）加入購物車 5）提交訂單 6）完成支付基於上面的討論咱們能夠構造一系列JMeter請求，放在一個線程組裏面。若是咱們要測試針對這樣的用戶，咱們的系統能夠支持多少人同時來購物。假設咱們已經考慮了用戶登陸帳號和購買商品的參數化問題，是否能夠直接將線程組的數值設置到一個較大的數值，而後併發執行呢？

這樣能夠執行起來，可是有一個很大的問題。在於真實用戶和腳本的不一樣。腳本若是是基於前面方法錄製的，兩個請求的執行時間以前是沒有任何其餘停頓的，其間隔只是依賴於上一個服務的響應時間和測試機發起請求所需的時間。可是顯然真實的用戶不是機器，他們在作上面每個步驟的時候都有一個思考的時間，這也是Think Time這個詞的意義來源。

固然，這個思考時間也是泛指，包括了用戶操做的時間，好比進入首頁後，用戶須要在搜索框中輸入想購買商品的關鍵詞，打開輸入法並輸入相關的詞可能也須要少則幾秒鐘的時間，搜索結果出來以後用戶須要瀏覽和選擇，找到感興趣的商品並點擊查看詳情，後面的步驟也是相似。試想一下，對比請求連續執行和每一個步驟間加入模擬真實用戶的Think Time以後，對於同一個系統，能支持的同時在線購物人數一定會有絕大的差別，而有Think Time的作法顯然更接近真實狀況。

準備工做

不一樣的機器、操做系統、web服務器以及相關參數等的不一樣，也會影響性能測試的結果。有必要在測試前對參數進行一下配置。
參考作一個正確的性能測試以及高負載系統，網絡參數調整進行調優。這裏列一下操做系統的幾個重要參數。

fs.file-max = 999999  
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.ip_local_port_range = 1024    61000
net.ipv4.tcp_rmem = 4096 32768 262142
net.ipv4.tcp_wmem = 4096 32768 262142
net.core.netdev_max_backlog = 8096
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 2097152
net.core.wmem_max = 2097152
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn.backlog=1024

file-max：這個參數表示進程（好比一個worker進程）能夠同時打開的最大句柄數，這個參數直接限制最大併發鏈接數，需根據實際狀況配置。
tcp_tw_reuse：這個參數設置爲1，表示容許將TIME-WAIT狀態的socket從新用於新的TCP鏈接，這對於服務器來講頗有意義，由於服務器上總會有大量TIME-WAIT狀態的鏈接。 - tcp_keepalive_time：這個參數表示當keepalive啓用時，TCP發送keepalive消息的頻度。默認是2小時，若將其設置得小一些，能夠更快地清理無效的鏈接。
tcp_fin_timeout：這個參數表示當服務器主動關閉鏈接時，socket保持在FIN-WAIT-2狀態的最大時間。
tcp_max_tw_buckets：這個參數表示操做系統容許TIME_WAIT套接字數量的最大值，若是超過這個數字，TIME_WAIT套接字將馬上被清除並打印警告信息。該參數默認爲180000，過多的TIME_WAIT套接字會使Web服務器變慢。
tcp_max_syn_backlog：這個參數表示TCP三次握手創建階段接收SYN請求隊列的最大長度，默認爲1024，將其設置得大一些可使出現Nginx繁忙來不及accept新鏈接的狀況時，Linux不至於丟失客戶端發起的鏈接請求。
ip_local_port_range：這個參數定義了在UDP和TCP鏈接中本地（不包括鏈接的遠端）端口的取值範圍。
net.ipv4.tcp_rmem：這個參數定義了TCP接收緩存（用於TCP接收滑動窗口）的最小值、默認值、最大值。
net.ipv4.tcp_wmem：這個參數定義了TCP發送緩存（用於TCP發送滑動窗口）的最小值、默認值、最大值。
netdev_max_backlog：當網卡接收數據包的速度大於內核處理的速度時，會有一個隊列保存這些數據包。這個參數表示該隊列的最大值。
rmem_default：這個參數表示內核套接字接收緩存區默認的大小。
wmem_default：這個參數表示內核套接字發送緩存區默認的大小。
rmem_max：這個參數表示內核套接字接收緩存區的最大大小。
wmem_max：這個參數表示內核套接字發送緩存區的最大大小。
tcp_syncookies：該參數與性能無關，用於解決TCP的SYN攻擊。

測試工具

性能測試工具的幾個核心的模塊

壓力生成器（Virtual User Generator）
結果採集器（Result Collector）
負載控制器（Controller）
系統資源監控器（Monitor）
結果分析器（Analysis）

由此能夠看出，像wrk、apache bench這類的工具，其實不算是完整的性能測試工具，由於它們並無系統資源監控器，這樣的話，其實簡單測試出來的結果並非很準確，只能說是簡單粗暴湊合着用。

被測系統資源監控

性能測試數據收集中很重要的一部分是被測系統的資源使用狀況，由於系統性能和資源使用是密切相關的，主要的目的有下面幾個方面：瞭解在當前壓力下，系統各項資源的使用狀況，也能夠用於橫向對比。經過資源使用狀況的分析能夠看出當前是否測出了系統最大的性能。是否有某項資源的使用已經到達上限，成爲瓶頸。是否有其餘非被測系統的模塊佔用了資源。一般在性能測試中，測試人員都會去收集CPU、內存、網絡等服務器資源使用狀況，可是若是隻是籠統地給出一個百分比是不夠的，須要進一步細分來提供更多有參考價值的數據。

所以若是隻是簡單地用wrk這類測試，記得關注被測試系統的cpu、io(網絡/文件)、內存等使用狀況。對於互聯網的應用，特別要關注網絡鏈接數。