LINUX壓力測試工具http_load、webbench、ab、siege

一、http_load

程序非常小,解壓後也不到100K

http_load以並行複用的方式運行,用以測試web服務器的吞吐量與負載。但是它不同於大多數壓力測試工具,它可以以一個單一的進程運行,一般不會把客戶機搞死。還可以測試HTTPS類的網站請求。


下載地址:http://soft.vpser.net/test/http_load/http_load-12mar2006.tar.gz


安裝

#tar zxvf http_load-12mar2006.tar.gz

#cd http_load-12mar2006

#make && make install


<!–more–>


命令格式:http_load  -p 併發訪問進程數  -s 訪問時間  需要訪問的URL文件

參數其實可以自由組合,參數之間的選擇並沒有什麼限制。比如你寫成http_load -parallel 5 -seconds

300 urls.txt也是可以的。我們把參數給大家簡單說明一下。

-parallel 簡寫-p :含義是併發的用戶進程數。

-fetches 簡寫-f :含義是總計的訪問次數

-rate    簡寫-p :含義是每秒的訪問頻率

-seconds簡寫-s :含義是總計的訪問時間

準備URL文件:urllist.txt,文件格式是每行一個URL,URL最好超過50-100個測試效果比較好.文件格式如下:

http://www.vpser.net/uncategorized/choose-vps.html

http://www.vpser.net/vps-cp/hypervm-tutorial.html

http://www.vpser.net/coupons/diavps-april-coupons.html

http://www.vpser.net/security/vps-backup-web-mysql.html

例如:

http_load -p 30 -s 60  urllist.txt

參數瞭解了,我們來看運行一條命令來看看它的返回結果

命令:% ./http_load -rate 5 -seconds 10 urls說明執行了一個持續時間10秒的測試,每秒的頻率爲5。

49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds5916 mean bytes/connection4.89274

fetches/sec, 28945.5 bytes/secmsecs/connect: 28.8932 mean, 44.243 max, 24.488 minmsecs/first

-response: 63.5362 mean, 81.624 max, 57.803 minHTTP response codes: code 200 — 49


結果分析:

1.49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds

說明在上面的測試中運行了49個請求,最大的併發進程數是2,總計傳輸的數據是289884bytes,運行的時間是10.0148秒

2.5916 mean bytes/connection說明每一連接平均傳輸的數據量289884/49=5916

3.4.89274 fetches/sec, 28945.5 bytes/sec

說明每秒的響應請求爲4.89274,每秒傳遞的數據爲28945.5 bytes/sec

4.msecs/connect: 28.8932 mean, 44.243 max, 24.488 min說明每連接的平均響應時間是28.8932 msecs,最大的響應時間44.243 msecs,最小的響應時間24.488 msecs

5.msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min

6、HTTP response codes: code 200 — 49     說明打開響應頁面的類型,如果403的類型過多,那可能


要注意是否系統遇到了瓶頸。

特殊說明:

測試結果中主要的指標是 fetches/sec、msecs/connect 這個選項,即服務器每秒能夠響應的查詢次數,用這個指標來衡量性能。似乎比 apache的ab準確率要高一些,也更有說服力一些。

Qpt-每秒響應用戶數和response time,每連接響應用戶時間。

測試的結果主要也是看這兩個值。當然僅有這兩個指標並不能完成對性能的分析,我們還需要對服務器的cpu、men進行分析,才能得出結論


二、webbench


webbench是Linux下的一個網站壓力測試工具,最多可以模擬3萬個併發連接去測試網站的負載能力。下載地址可以到google搜,我這裏給出一個

下載地址:http://soft.vpser.net/test/webbench/webbench-1.5.tar.gz

這個程序更小,解壓後不到50K,呵呵


安裝

#tar zxvf webbench-1.5.tar.gz

#cd webbench-1.5

#make && make install

會在當前目錄生成webbench可執行文件,直接可以使用了


用法:

webbench -c 併發數 -t 運行測試時間 URL

如:

webbench -c 5000 -t 120 http://www.163.com


三、ab


選項


-A auth-username:password

對服務器提供BASIC認證信任。 用戶名和密碼由一個:隔開,並以base64編碼形式發送。 無論服務器是否需要(即, 是否發送了401認證需求代碼),此字符串都會被髮送。

-c concurrency

一次產生的請求個數。默認是一次一個。

-C cookie-name=value

對請求附加一個Cookie:行。 其典型形式是name=value的一個參數對。 此參數可以重複。

-d

不顯示”percentage served within XX [ms] table”的消息(爲以前的版本提供支持)。

-e csv-file

產生一個以逗號分隔的(CSV)文件, 其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙爲單位)時間。 由於這種格式已經“二進制化”,所以比’gnuplot’格式更有用。

-g gnuplot-file

把所有測試結果寫入一個’gnuplot’或者TSV (以Tab分隔的)文件。 此文件可以方便地導入到Gnuplot, IDL, Mathematica, Igor甚至Excel中。 其中的第一行爲標題。

-h

顯示使用方法。

-H custom-header

對請求附加額外的頭信息。 此參數的典型形式是一個有效的頭信息行,其中包含了以冒號分隔的字段和值的對 (如, “Accept-Encoding: zip/zop;8bit”).

-i

執行HEAD請求,而不是GET。

-k

啓用HTTP KeepAlive功能,即, 在一個HTTP會話中執行多個請求。 默認時,不啓用KeepAlive功能.

-n requests

在測試會話中所執行的請求個數。 默認時,僅執行一個請求,但通常其結果不具有代表意義。

-p POST-file

包含了需要POST的數據的文件.

-P proxy-auth-username:password

對一箇中轉代理提供BASIC認證信任。 用戶名和密碼由一個:隔開,並以base64編碼形式發送。 無論服務器是否需要(即, 是否發送了401認證需求代碼),此字符串都會被髮送。

-q

如果處理的請求數大於150, ab每處理大約10%或者100個請求時,會在stderr輸出一個進度計數。 此-q標記可以抑制這些信息。

-s

用於編譯中(ab -h會顯示相關信息)使用了SSL的受保護的https, 而不是http協議的時候。此功能是實驗性的,也是很簡陋的。最好不要用。

-S

不顯示中值和標準背離值, 而且在均值和中值爲標準背離值的1到2倍時,也不顯示警告或出錯信息。 默認時,會顯示 最小值/均值/最大值等數值。(爲以前的版本提供支持).

-t timelimit

測試所進行的最大秒數。其內部隱含值是-n 50000。 它可以使對服務器的測試限制在一個固定的總時間以內。默認時,沒有時間限制。

-T content-type

POST數據所使用的Content-type頭信息。

-v verbosity

設置顯示信息的詳細程度 – 4或更大值會顯示頭信息, 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其他信息。

-V

顯示版本號並退出。

-w

以HTML表的格式輸出結果。默認時,它是白色背景的兩列寬度的一張表。

-x <table>-attributes

設置<table>屬性的字符串。 此屬性被填入<table 這裏 >.

-X proxy[:port]

對請求使用代理服務器。

-y <tr>-attributes

設置<tr>屬性的字符串.

-z <td>-attributes

設置<td>屬性的字符串.


缺陷

程序中有各種靜態聲明的固定長度的緩衝區。 另外,對命令行參數、服務器的響應頭和其他外部輸入的解析也很簡單,這可能會有不良後果。


它沒有完整地實現HTTP/1.x; 僅接受某些’預想’的響應格式。 strstr(3)的頻繁使用可能會帶來性能問題,即, 你可能是在測試ab而不是服務器的性能。


 


參數很多,一般我們用 -c 和 -n 參數就可以了. 例如:


./ab -c 1000 -n 1000 http://127.0.0.1/index.php


這個表示同時處理1000個請求並運行1000次index.php文件.

#/usr/local/xiaobai/apache2054/bin/ab -c 1000 -n 1000 http://127.0.0.1/index.html.zh-cn.gb2312

This is ApacheBench, Version 2.0.41-dev <$Revision: 1.121.2.12 $> apache-2.0

Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/


Benchmarking 127.0.0.1 (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Finished 1000 requests


Server Software: Apache/2.0.54

//平臺apache 版本2.0.54

Server Hostname: 127.0.0.1

//服務器主機名

Server Port: 80

//服務器端口


Document Path: /index.html.zh-cn.gb2312

//測試的頁面文檔

Document Length: 1018 bytes

//文檔大小


Concurrency Level: 1000

//併發數

Time taken for tests: 8.188731 seconds

//整個測試持續的時間

Complete requests: 1000

//完成的請求數量

Failed requests: 0

//失敗的請求數量

Write errors: 0


Total transferred: 1361581 bytes

//整個場景中的網絡傳輸量

HTML transferred: 1055666 bytes

//整個場景中的HTML內容傳輸量

Requests per second: 122.12 [#/sec] (mean)

//大家最關心的指標之一,相當於 LR 中的 每秒事務數 ,後面括號中的 mean 表示這是一個平均值

Time per request: 8188.731 [ms] (mean)

//大家最關心的指標之二,相當於 LR 中的 平均事務響應時間 ,後面括號中的 mean 表示這是一個平均值

Time per request: 8.189 [ms] (mean, across all concurrent requests)

//每個請求實際運行時間的平均值

Transfer rate: 162.30 [Kbytes/sec] received

//平均每秒網絡上的流量,可以幫助排除是否存在網絡流量過大導致響應時間延長的問題


Connection Times (ms)

min mean[+/-sd] median max

Connect: 4 646 1078.7 89 3291

Processing: 165 992 493.1 938 4712

Waiting: 118 934 480.6 882 4554

Total: 813 1638 1338.9 1093 7785

//網絡上消耗的時間的分解,各項數據的具體算法還不是很清楚


Percentage of the requests served within a certain time (ms)

50% 1093

66% 1247

75% 1373

80% 1493

90% 4061

95% 4398

98% 5608

99% 7368

100% 7785 (longest request)

//整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間,其中50%的用戶響應時間小於1093 毫秒,60% 的用戶響應時間小於1247 毫秒,最大的響應時間小於7785 毫秒


由於對於併發請求,cpu實際上並不是同時處理的,而是按照每個請求獲得的時間片逐個輪轉處理的,所以基本上第一個Time per request時間約等於第二個Time per request時間乘以併發請求數


四、Siege

一款開源的壓力測試工具,可以根據配置對一個WEB站點進行多用戶的併發訪問,記錄每個用戶所有請求過程的相應時間,並在一定數量的併發訪問下重複進行。

官方:http://www.joedog.org/

Siege下載:http://soft.vpser.net/test/siege/siege-2.67.tar.gz

解壓:

# tar -zxf siege-2.67.tar.gz

進入解壓目錄:

# cd siege-2.67/

安裝:

#./configure ; make

#make install


使用

siege -c 200 -r 10 -f example.url

-c是併發量,-r是重複次數。 url文件就是一個文本,每行都是一個url,它會從裏面隨機訪問的。


example.url內容:


http://www.licess.cn

http://www.vpser.net

http://soft.vpser.net


結果說明

Lifting the server siege… done.

Transactions: 3419263 hits //完成419263次處理

Availability: 100.00 % //100.00 % 成功率

Elapsed time: 5999.69 secs //總共用時

Data transferred: 84273.91 MB //共數據傳輸84273.91 MB

Response time: 0.37 secs //相應用時1.65秒:顯示網絡連接的速度

Transaction rate: 569.91 trans/sec //均每秒完成 569.91 次處理:表示服務器後

Throughput: 14.05 MB/sec //平均每秒傳送數據

Concurrency: 213.42 //實際最高併發數

Successful transactions: 2564081 //成功處理次數

Failed transactions: 11 //失敗處理次數

Longest transaction: 29.04 //每次傳輸所花最長時間

Shortest transaction: 0.00 //每次傳輸所花最短時間


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