1. 程式人生 > >效能壓力測試工具之ApacheBench

效能壓力測試工具之ApacheBench

ApacheBench命令原理:

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

 

 

執行的程式

Win系統下,開啟cmd命令列視窗,cd到apache安裝目錄的bin目錄下

語法及引數

ab [options] [http[s]://]hostname[:port]/path
引數選項


Options are:
    -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)
 

案例:

ab -n 4000 -c 1000 http://localhost:8080/EX2/responseCode

-n後面的4000代表總共發出4000個請求;-c後面的1000表示採用1000個併發(模擬1000個人同時訪問),後面的網址表示測試的目標URL。

 

H:\java\Apache24\bin>ab -n 4000 -c 1000 http://localhost:8080/EX2/responseCode


This is ApacheBench, Version 2.3 <$Revision: 1843412 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 400 requests
Completed 800 requests
Completed 1200 requests
Completed 1600 requests
Completed 2000 requests
Completed 2400 requests
Completed 2800 requests
Completed 3200 requests
Completed 3600 requests
Completed 4000 requests
Finished 4000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        localhost 	//測試地址
Server Port:            8080 		//測試埠

Document Path:          /EX2/responseCode //測試的url
Document Length:        2 bytes 	//文件大小(該測試返回的內容只有OK兩字)

Concurrency Level:      1000  		//測試的併發數
Time taken for tests:   1.806 		//seconds 整個測試持續的時間
Complete requests:      4000 		//完成的請求數量
Failed requests:        0 			//失敗的請求數量
Non-2xx responses:      4000
Total transferred:      668000 bytes //整個過程中的網路傳輸量
HTML transferred:       8000 bytes   //整個過程中的HTML內容傳輸量
Requests per second:    2214.84 [#/sec] (mean) 	//重要指標:相當於LR中的每秒事務數,後面括號中的mean表示這是一個平均值
Time per request:       451.500 [ms] (mean) 	//重要指標:當於LR中的平均事務響應時間,後面括號中的mean表示這是一個平均值
Time per request:       0.452 [ms] (mean, across all concurrent requests)//每個連線請求實際執行時間的平均值
Transfer rate:          361.21 [Kbytes/sec] received //平均每秒網路上的流量,可以幫助排除是否存在網路流量過大導致響應時間延長的問題

Connection Times (ms) min  mean[+/-sd] median   max
Connect:       			0    0   8.0      0     504
Processing:    			54  298 127.9    307     825
Waiting:        		3  173 152.9    148     813
Total:         			54  298 128.1    307     825

Percentage of the requests served within a certain time (ms)
  50%    307
  66%    313
  75%    314
  80%    315
  90%    315
  95%    317
  98%    821
  99%    824
 100%    825 (longest request)
 //其中50%的使用者響應時間小於307毫秒,66%的使用者響應時間小於313毫秒,最大的響應時間小於825毫秒。對於併發請求,cpu實際上並不是同時處理的,而是按照每個請求獲得的時間片逐個輪轉處理的,所以基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數