ab test壓力測試

之前做性能調試的時候一直用的JMeter壓測,最近發現一款簡單易用的壓力測試工具。 ab(Apache benchmark)是一款常用的壓力測試工具,是Apache附帶的一個小工具 , 專門用於HTTP Server的benchmark testing,可以同時模擬多個併發請求。

v基礎知識

ab的原理:ab命令會創建多個併發訪問線程,模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基於URL的,因此,它既可以用來測試apache的負載壓力,也可以測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。ab命令對發出負載的計算機要求很低,它既不會佔用很高CPU,也不會佔用很多內存。但卻會給目標服務器造成巨大的負載,其原理類似CC攻擊。自己測試使用也需要注意,否則一次上太多的負載。可能造成目標服務器資源耗完,嚴重時甚至導致死機。

先介紹幾個性能指標。

吞吐率:服務器併發處理能力的量化描述,單位是reqs/s,指的是某個併發用戶數下單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數,稱之爲最大吞吐率。

併發連接數:某一時刻服務器所接受的請求數(會話數)。

併發用戶數:某一時刻服務器所接受的連接數,一個用戶可能同時產生多個連接。

用戶平均請求等待時間:總請求數 / 併發用戶數。

服務器平均請求等待時間:處理完成所有請求數所花費的時間 / 總請求數。

PV: 即page view,頁面瀏覽量,用戶每一次對網站中的每個頁面訪問均被記錄1次。用戶對同一頁面的多次刷新,訪問量累計。

UV:即Unique visitor,獨立訪客,通過客戶端的cookies實現。即同一頁面,客戶端多次點擊只計算一次,訪問量不累計。

IP: 即Internet Protocol,本意本是指網絡協議,在數據統計這塊指通過ip的訪問量。即同一頁面,客戶端使用同一個IP訪問多次只計算一次,訪問量不累計。

TPS:即Transactions Per Second的縮寫,每秒處理的事務數目。一個事務是指一個客戶機向服務器發送請求然後服務器做出反應的過程。客戶機在發送請求時開始計時,收到服務器響應後結束計時,以此來計算使用的時間和完成的事務個數,最終利用這些信息作出的評估分。

QPS:即Queries Per Second的縮寫,每秒能處理查詢數目。是一臺服務器每秒能夠相應的查詢次數,是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。QPS=併發量 / 平均響應時間

RPS:即Requests Per Second的縮寫,每秒能處理的請求數目。等效於QPS

vWindows安裝ab test

1.1 下載地址

https://www.apachehaus.com/cgi-bin/download.plx

ab test壓力測試

1.2 解壓

ab test壓力測試

用CMD命令行打開解壓後的bin目錄路徑。

ab test壓力測試

1.3 測試

ab -n 100 -c 10 http://toutou.com:8301/user/get?uid=1

-n 表示請求數,-c 表示併發數. -t 表示多少s內併發和請求

上面的命令測試總次數爲100,併發數爲10(相當於10個用戶同時訪問,他們總共訪問100次)。

ab test壓力測試

在解析返回結果之前,我們先來看看如果宿主機由Windows換成Linux後,如何在Linux上使用ab test。

vLinux安裝ab test

2.1 安裝ab test

yum -y install httpd-tools

ab -V

ab test壓力測試

2.2 測試

ab test壓力測試

v參數/返回結果

3.1 參數

用法:ab [選項] 地址

Usage: ab [options] [http[s]://]hostname[:port]/path

-n requests    #執行的請求數,即一共發起多少請求。
    -c concurrency    #請求併發數。
    -t timelimit    #測試所進行的最大秒數。其內部隱含值是-n 50000,它可以使對服務器的測試限制在一個固定的總時間以內。默認時,沒有時間限制。
    -s timeout    #指定每個請求的超時時間,默認是30秒。
    -b windowsize    #指定tcp窗口的大小,單位是字節。
    -B address    #指定在發起連接時綁定的ip地址是什麼。
    -p postfile    #指定要POST的文件,同時要設置-T參數。
    -u putfile    #指定要PUT的文件,同時要設置-T參數。
    -T content-type    #指定使用POST或PUT上傳文本時的文本類型,默認是'text/plain'。
    -v verbosity    #設置詳細模式等級。
    -w    #將結果輸出到html的表中。
    -i    #使用HEAD方式代替GET發起請求。
    -y attributes    #以表格方式輸出時,設置html表格tr屬性。 
    -z attributes    #以表格方式輸出時,設置html表格th或td屬性。
    -C attribute    #添加cookie,比如'Apache=1234'。(可重複)
    -H attribute    #爲請求追加一個額外的頭部,比如'Accept-Encoding: gzip'。(可重複)
    -A attribute    #對服務器提供BASIC認證信任。用戶名和密碼由一個:隔開,並以base64編碼形式發送。無論服務器是否需要(即,是否發送了401認證需求代碼),此字符串都會被髮送。
    -P attribute    #對一箇中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開,並以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼),此字符串都會被髮送。
    -X proxy:port   #指定代理服務器的IP和端口。
    -V              #打印版本信息。
    -k              #啓用HTTP KeepAlive功能,即在一個HTTP會話中執行多個請求。默認時,不啓用KeepAlive功能。
    -d              #不顯示"percentage served within XX [ms] table"的消息(爲以前的版本提供支持)。
    -q              #如果處理的請求數大於150,ab每處理大約10%或者100個請求時,會在stderr輸出一個進度計數。此-q標記可以抑制這些信息。
    -g filename     #把所有測試結果寫入一個'gnuplot'或者TSV(以Tab分隔的)文件。此文件可以方便地導入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行爲標題。
    -e filename     #產生一個以逗號分隔的(CSV)文件,其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙爲單位)時間。由於這種格式已經“二進制化”,所以比'gnuplot'格式更有用。
    -r              #當收到錯誤時不要退出。
    -h              #輸出幫助信息
    -Z ciphersuite  指定SSL/TLS密碼套件
    -f protocol     指定SSL/TLS協議(SSL3, TLS1, TLS1.1, TLS1.2 or ALL)

3.2 返回結果

以上文中Linux ab test的結果集爲例:

[root@localhost ~]# ab -n 100 -c 10 http://toutou.com:8301/user/get?uid=1
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking toutou.com (be patient).....done

#測試服務器的名字
Server Software:      
#請求的URL主機名  
Server Hostname:        toutou.com
#web服務器監聽的端口
Server Port:            8301

 #請求的URL中的根絕對路徑
Document Path:          /user/get?uid=1
#HTTP響應數據的正文長度
Document Length:        131 bytes

# 併發用戶數,這是ab命令中設置的-c參數
Concurrency Level:      10
 #所有這些請求被處理完成所花費的總時間
Time taken for tests:   1.274 seconds
# 總請求數量,這是ab命令中設置的-n參數
Complete requests:      100
 # 失敗的請求數,這裏的失敗是指請求的連接服務器、發送數據、接收數據等環節發生異常,以及無響應後超時的情況。對於超時時間的設置可以用ab的-t參數。如果接受到的http響應數據的頭信息中含有2xx以外的狀態碼,則會在測試結果顯示另一個名爲“Non-2xx responses”的統計項,用於統計這部分請求數,這些請求並不算是失敗的請求。
Failed requests:        0
#寫入錯誤
Write errors:           0
# 總的網絡傳輸量(字節數),包含http的頭信息等。使用ab的-v參數即可查看詳細的http頭信息。
Total transferred:      25000 bytes
# HTML內容傳輸量,實際的頁面傳遞字節數。也就是減去了Total transferred中http響應數據中頭信息的長度。
HTML transferred:       13100 bytes
# 每秒處理的請求數,服務器的吞吐量,等於:Complete requests / Time taken for tests(QPS)
Requests per second:    78.48 [#/sec] (mean)
# 用戶平均請求等待時間
Time per request:       127.425 [ms] (mean)
# 服務器平均處理時間
Time per request:       12.743 [ms] (mean, across all concurrent requests)
# 平均每秒網絡上的流量,即每秒收到的速率
Transfer rate:          19.16 [Kbytes/sec] received
 
# 壓力測試時的連接處理時間。-- min最小值、mean平均值、[+/-sd]方差、median中位數、maxz最大值
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   0.3      0       1                 # socket鏈路建立消耗,代表網絡狀況好
Processing:    20  121  54.9    119     281          # 寫入緩衝區消耗+鏈路消耗+服務器消耗
Waiting:       13   99  48.7     93     234             # 寫入緩衝區消耗+鏈路消耗+服務器消耗+讀取數據消耗
Total:         21  122  54.8    119     281              # 單個事務總時間
ERROR: The median and mean for the initial connection time are more than twice the standard
       deviation apart. These results are NOT reliable.

Percentage of the requests served within a certain time (ms)
  50%    119
  66%    141
  75%    148
  80%    159
  90%    201
  95%    232
  98%    268
  99%    281
 100%    281 (longest request)
# 整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間,其中50%的用戶響應時間小於119毫秒,66%的用戶響應時間小於141毫秒,最大的響應時間小於281毫秒

3.3 從上面的返回結果可以得出以下數據:

1.整個測試持續的時間:1.274s

2.完成的請求數:1000

3.失敗的請求數:0

4.總的網絡傳輸量(字節數):25000 bytes

5.HTML內容傳輸量:13100 bytes

6.服務器的吞吐量:78.48 (QPS的穩定值應取決於失敗請求爲0時支持的最高併發)

7.用戶平均請求等待時間:127.425ms

8.服務器平均處理時間:12.743ms

9.平均每秒網絡上的流量: 19.16kb

10.99%的用戶響應時間小於181ms

v遇到的問題

4.1.1: 錯誤描述

apr_socket_recv: Connection reset by peer (104) 
Total of 2513 requests completed

4.1.2: 解決方案

這個參數的意思是當出現“receive error”,即接收數據錯誤時是否退出,默認是退出的,所以會出現上述的問題,在參數中加入 -r 參數即可。

4.2.1: 錯誤描述

Benchmarking toutou.com (be patient) 
socket: Too many open files (24)

4.2.2: 解決方案

調整可以打開的文件數: ulimit -n 65535

v博客總結

1.ab判斷成功與否知識判斷 2xx 響應碼,不接收服務器的返回值,所以同樣的響應ab測試支持的併發數大於LR和Jemter,TPS的響應值也會比較大

2.ab運行的測試併發數與ab所運行的機器的cpu的顆粒度有很大的關係,cpu顆粒度越大,測試結果支持的併發數越大

3.ab不像LR或Jemter那麼強大,但是它足夠輕便,如果只是在開發過程中想檢查一下某個模塊的響應情況,或者做一些場景比較簡單的測試,ab還是一個不錯的選擇。

其他參考/學習資料:

 

v源碼地址

https://github.com/toutouge/javademosecond/tree/master/hellospringboot


作  者:請叫我頭頭哥
出  處:http://www.cnblogs.com/toutou/
關於作者:專注於基礎平臺的項目開發。如有問題或建議,請多多賜教!
版權聲明:本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文鏈接。
特此聲明:所有評論和私信都會在第一時間回覆。也歡迎園子的大大們指正錯誤,共同進步。或者直接私信
聲援博主:如果您覺得文章對您有幫助,可以點擊文章右下角推薦一下。您的鼓勵是作者堅持原創和持續寫作的最大動力!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章