一、簡介
Webbench是知名的網站壓力測試工具，能測試處在相同硬件上，不同服務的性能以及不同硬件上同一個服務的運行狀況。
webbench的標准測試可以向我們展示服務器的兩項內容：每秒鍾相應請求數和每秒鍾傳輸數據量。
Webbench最多可以模擬3萬個並發連接去測試網站的負載能力
二、安裝webbench-1.5.tar.gz
1、將webbench-1.5.tar.gz文件上傳至服務器的/opt/目錄下；
2、對webbench-1.5.tar.gz文件進行解壓操作：
[root@besttest opt]# tar -xvf webbench-1.5.tar.gz
webbench-1.5/
webbench-1.5/webbench.1
webbench-1.5/socket.c
webbench-1.5/webbench.c
webbench-1.5/Makefile
webbench-1.5/debian/
webbench-1.5/debian/rules
webbench-1.5/debian/dirs
webbench-1.5/debian/copyright
webbench-1.5/debian/control
webbench-1.5/debian/changelog
webbench-1.5/COPYRIGHT
webbench-1.5/ChangeLog
3、進入webbench-1.5目錄進行編譯操作：
[root@besttest opt]# cd webbench-1.5
[root@besttest webbench-1.5]# make &&make install
-bash: make: command not found
安裝make編譯器：
[root@besttest webbench-1.5]# yum -y install make
再次進行編譯操作：
[root@besttest webbench-1.5]# make && make install
cc -Wall -ggdb -W -O -c -o webbench.o webbench.c
make: cc：命令未找到
提示cc命令未找到，安裝gcc編譯器：
[root@besttest ~]# yum -y install gcc automake autoconf libtool make
再次進行make編譯：
[root@besttest webbench-1.5]# make && make install
cc -Wall -ggdb -W -O -c -o webbench.o webbench.c
webbench.c: 在函數‘alarm_handler’中:
webbench.c:77: 警告：未使用的參數‘signal’
cc -Wall -ggdb -W -O -o webbench webbench.o
ctags *.c
/bin/sh: ctags: command not found
make: [tags] 錯誤 127 (忽略)
install -s webbench /usr/local/bin
install -m 644 webbench.1 /usr/local/man/man1
install: 無法創建普通文件"/usr/local/man/man1": 沒有那個文件或目錄
編譯成功：
[root@besttest webbench-1.5]# ll webbench
-rwxr-xr-x. 1 root root 24442 5月 10 18:55 webbench
webbench的使用說明：
[root@besttest webbench-1.5]# ./webbench
webbench [option]... URL
-f|--force Don't wait for reply from server.
-r|--reload Send reload request - Pragma: no-cache.
-t|--time <sec> Run benchmark for <sec> seconds. Default 30.
-p|--proxy <server:port> Use proxy server for request.
-c|--clients <n> Run <n> HTTP clients at once. Default one.
-9|--http09 Use HTTP/0.9 style requests.
-1|--http10 Use HTTP/1.0 protocol.
-2|--http11 Use HTTP/1.1 protocol.
--get Use GET request method.
--head Use HEAD request method.
--options Use OPTIONS request method.
--trace Use TRACE request method.
-?|-h|--help This information.
-V|--version Display program version.
三、使用
[root@besttest webbench-1.5]# ./webbench -t 30 -c 10 http://sports.163.com/
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://sports.163.com/
10 clients, running 30 sec.
Speed=54 pages/min, 423497 bytes/sec.
Requests: 27 susceed, 0 failed.
由執行結果可以算出tps的值：tps=Requests27/30sec
但是不知道任務是對還是錯，在日志中查看
[root@besttest webbench-1.5]# ./webbench -t 1 -c 1 http://192.168.20.128/bugfree/index.php/site/login/
Webbench - Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.
Benchmarking: GET http://192.168.20.128/bugfree/index.php/site/login/
1 client, running 1 sec.
Speed=1979 pages/min, 143286 bytes/sec.
Requests: 33 susceed, 0 failed.
[root@besttest logs]# cat access_log |grep "/bugfree/index.php/site/login/ HTTP/1.0" | wc -l
34
為什么100個並發的時候比10個並發所發的請求數要少，因服務器的處理能力有限，服務器處理不過來，cpu切片。
四、測試結果分析
1、測試環境(軟件、硬件、數據庫數據、腳本、測試場景等)
判斷2xx狀態，不接收服務器的返回值
2、同時lr測試，環境都一樣，數據不一樣(2.1,2.3秒)
每一次的執行結果會不一樣(why?差異在可接受范圍內)
出現差異怎么辦：多次測試取平均值
3、lr測試：2.9s 開發：日志打印1.8s
1)排除開發打的計時是否正確(請求數lr使用錄制html方式錄制，一個html請求可能對應多個url請求等)
2)client → webservice(代碼、web容器) → db
①客戶端發送請求時間
②請求傳輸時間
③服務器空閑線程取請求
④服務器代碼執行時間
⑤請求傳輸到數據庫時間
⑥數據庫線程池拿到請求的時間
⑦數據庫語法檢查、語義分析、open表、生成執行計划、按照執行計划到內存或者磁盤中拿數據到內存中再返回、DML處理時間
⑧數據庫處理結果返回到服務器時間
⑨服務器線程喚醒的時間
⑩服務器執行代碼的時間
①①服務器執行結果返回客戶端的時間
①②客戶端接收數據的時間
開發的響應時間：比方說，在代碼的調用sql前開始計時，執行完相關方法后停止計時，並且打印時間，從第④步開始計時到代碼塊執行完畢的時間，第⑩步的執行時間
響應時間相差大，慢在哪里？
分析：
步驟① ② ③ ①① ①②會慢，client端口是否有問題、網絡是否有問題、線程池是否有性能問題(拿不到線程)