ab的全稱是ApacheBench，是 Apache 附帶的一個小工具，專門用于 HTTP Server 的benchmark testing，可以同時模擬多個并發請求。這個小工具在apache的bin目錄下面，但是每次使用都要先跳到該目錄下，為了能夠直接在cmd下使用，可以講ab.exe這個文件移到C:\WINDOWS\system32路徑下，這樣每次使用就很方便了。
loadrunner用的好好的為什么要研究這個ab呢？我給我自己的理由是：
1.ab是開源的，很多大公司都喜歡開源的因為loadrunner太貴了，所以想成為一個性能測試高手必須要懂幾個開源的性能測試工具，個人意見；
2.ab這個工具小巧使用并且很簡單，上手快學習起來比較簡單，而loadrunner相比起來就太復雜了，腳本開發拋開不說，就loadrunner這個工具就夠學上個一個月的。
3.ab雖然很小，但是功能還是 很強大的，提供的數據足夠我們使用了，其實loadrunner中雖然提供了很多功能，但是我們用能使用多少呢，性能監控這塊，我 基本不用全部都是第三方監控或者linux命令，loadrunner中給出的很多指標對我們很有用的也就是1、事物的響應時間 2、事物的成功率 3、系統的吞吐量 3、在單位時間內完成的事物數這些ab基本上都可以實現。
4.如果遇到臨時任務或者很簡單的一個測試，可以這么說吧，開發寫了一個接口讓你幫他看一下性能如何，只需大概，正好你有沒有loadrunner安裝包，那怎么辦呢，其他不說就下個loadrunner安裝包估計就讓開發等的不耐煩了，使用ab就不一樣了很快就可以給他結果；
總而言之2者各有特點，如果做大項目，邏輯關系比較復雜的項目ab就無能為力了，所以做為一名性能測試人員就必須掌握2~3種性能測試工具，不同情況下可以使用不同的測試工具。
說了這么對廢話，咱們下面就看一看這塊小巧的性能測試工具吧：
我們在使用一個新工具之前當然首先看的幫助文檔了，那下面我們就看看ab這個工具的幫助文檔：
-n requests Number of requests to perform
//在測試會話中所執行的請求個數。默認時，僅執行一個請求
-c concurrency Number of multiple requests to make
//一次產生的請求個數。默認是一次一個。
-t timelimit Seconds to max. wait for responses
//測試所進行的最大秒數。其內部隱含值是-n 50000。它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。
-p postfile File containing data to POST
//包含了需要POST的數據的文件.
-T content-type Content-type header for POSTing
//POST數據所使用的Content-type頭信息。
-v verbosity How much troubleshooting info to print
//設置顯示信息的詳細程度 - 4或更大值會顯示頭信息， 3或更大值可以顯示響應代碼(404, 200等), 2或更大值可以顯示警告和其他信息。 -V 顯示版本號并退出。
-w Print out results in HTML tables
//以HTML表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-i Use HEAD instead of GET
// 執行HEAD請求，而不是GET。
-x attributes String to insert as table attributes
//
-y attributes String to insert as tr attributes
//
-z attributes String to insert as td or th attributes
//
-C attribute Add cookie, eg. 'Apache=1234. (repeatable)
//-C cookie-name=value 對請求附加一個Cookie:行。 其典型形式是name=value的一個參數對。此參數可以重復。
-H attribute Add Arbitrary header line, eg. 'Accept-Encoding: gzip'
Inserted after all normal header lines. (repeatable)
-A attribute Add Basic WWW Authentication, the attributes
are a colon separated username and password.
-P attribute Add Basic Proxy Authentication, the attributes
are a colon separated username and password.
//-P proxy-auth-username:password 對一個中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開，并以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被發送。
-X proxy:port Proxyserver and port number to use
-V Print version number and exit
-k Use HTTP KeepAlive feature
-d Do not show percentiles served table.
-S Do not show confidence estimators and warnings.
-g filename Output collected data to gnuplot format file.
-e filename Output CSV file with percentages served
-h Display usage information (this message)
|
下面是一個很簡單的例子：
ab -n 100 -c 10 http://www.baidu.com/
向百度發送100個請求，以10個并發用戶同時進行，這就模擬了loadrunner中的并發用戶了
his 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) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking www.baidu.com (be patient).....done
Server Software: BWS/1.0 //被測試平臺使用的web服務器
Server Hostname: www.baidu.com
//服務器主機名
Server Port: 80
//服務器端口號
Document Path: /
//測試的頁面的路徑，這是在根目錄下
Document Length: 7677 bytes
//測試的頁面的大小
Concurrency Level: 10 //并發數
Time taken for tests: 9.187500 seconds //整個測試持續的時間
Complete requests: 100 //總共完成的請求數
Failed requests: 0 //失敗的請求數量
Write errors: 0
Total transferred: 805879 bytes //整個場景中的網絡傳輸量
HTML transferred: 767700 bytes//整個場景中的HTML內容傳輸量
Requests per second: 10.88 [#/sec] (mean)//大家最關心的指標之一，相當于 LR 中的 每秒事務數 ，后面括號中的 mean 表示這是一個平均值
Time per request: 918.750 [ms] (mean)//大家最關心的指標之二，相當于 LR 中的 平均事務響應時間 ，后面括號中的 mean 表示這是一個平均值
Time per request: 91.875 [ms] (mean, across all concurrent requests)//每個請求實際運行時間的平均值
Transfer rate: 85.55 [Kbytes/sec] received//平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 90 76.4 62 343
Processing: 47 792 277.9 844 1265
Waiting: 15 434 285.2 406 1203
Total: 93 883 296.5 937 1390 //網絡上消耗的時間的分解，相當于loadrunner中的網頁細分圖
Percentage of the requests served within a certain time (ms)
50% 937
66% 1000
75% 1078
80% 1140
90% 1218
95% 1250
98% 1312
99% 1390
100% 1390 (longest request) |
//整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小于937 毫秒，60％ 的用戶響應時間小于1000 毫秒，最大的響應時間小于1390 毫秒
由于對于并發請求，cpu實際上并不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個Time per request時間約等于第二個Time per request時間乘以并發請求數