使用ab進行壓力測試

轉載至http://www.ha97.com/4617.html

PS：網站性能壓力測試是性能調優過程中必不可少的一環。隻有讓伺服器處在高壓情況下才能真正展現出各種設定所暴露的問題。Apache中有個自帶的，名為ab的程式，可以對Apache或其它類型的伺服器進行網站通路壓力測試。

ab這種工具對于壓力測試來說不是很有說服力，推薦jmeter或者loadrunner，壓力測試的時候要保證測試的響應時間曲線穩定住一定時間後，才認為是目前被測試伺服器的真實性能，因為剛開始測試的時候需要一定預熱時間，一般測試到一定時間之後曲線會穩定住，這時候再判斷目前的響應時間。

ApacheBench指令原理：

ab指令會建立很多的并發通路線程，模拟多個通路者同時對某一URL位址進行通路。它的測試目标是基于URL的，是以，既可以用來測試Apache的負載壓力，也可以測試nginx、lighthttp、tomcat、IIS等其它Web伺服器的壓力。

ab指令對發出負載的計算機要求很低，既不會占用很高CPU，也不會占用很多記憶體，但卻會給目标伺服器造成巨大的負載，其原理類似CC攻擊。自己測試使用也須注意，否則一次上太多的負載，可能造成目标伺服器因資源耗完，嚴重時甚至導緻當機。

ApacheBench參數說明

格式：ab [options] [http://]hostname[:port]/path

參數說明：

-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的資料的檔案，檔案格式如“p1=1&p2=2”.使用方法是 -p 111.txt 。 （配合-T）

-T content-type Content-type header for POSTing

//POST資料所使用的Content-type頭資訊，如 -T “application/x-www-form-urlencoded” 。 （配合-p）

-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. -C “c1=1234,c2=2,c3=3″ (repeatable)

//-C cookie-name=value 對請求附加一個Cookie:行。 其典型形式是name=value的一個參數對。此參數可以重複，用逗号分割。

提示：可以借助session實作原理傳遞 JSESSIONID參數， 實作保持會話的功能，如

-C ” c1=1234,c2=2,c3=3, JSESSIONID=FF056CD16DA9D71CB131C1D56F0319F8″ 。

-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

//-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)

//-attributes 設定屬性的字元串.

缺陷程式中有各種靜态聲明的固定長度的緩沖區。另外，對指令行參數、伺服器的響應頭和其他外部輸入的解析也很簡單，這可能會有不良後果。它沒有完整地實作

HTTP/1.x; 僅接受某些’預想’的響應格式。 strstr(3)的頻繁使用可能會帶來性能問題，即你可能是在測試ab而不是伺服器的性能。

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

# ab -c 5000 -n 600 http://127.0.0.1/index.php

ApacheBench用法詳解：

在Linux系統，一般安裝好Apache後可以直接執行；

# ab -n 4000 -c 1000 http://www.ha97.com/

如果是Win系統下，打開cmd指令行視窗，cd到apache安裝目錄的bin目錄下；

-n後面的4000代表總共發出4000個請求；-c後面的1000表示采用1000個并發（模拟1000個人同時通路），後面的網址表示測試的目标URL。

稍等一會得到類似如下顯示結果：

結果分析：

This is ApacheBench, Version 2.3

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

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 192.168.80.157 (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/2.2.15

Server Hostname: 192.168.80.157

Server Port: 80

Document Path: /phpinfo.php

#測試的頁面

Document Length: 50797 bytes

#頁面大小

Concurrency Level: 1000

#測試的并發數

Time taken for tests: 11.846 seconds

#整個測試持續的時間

Complete requests: 4000

#完成的請求數量

Failed requests: 0

#失敗的請求數量

Write errors: 0

Total transferred: 204586997 bytes

#整個過程中的網絡傳輸量

HTML transferred: 203479961 bytes

#整個過程中的HTML内容傳輸量

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

#最重要的名額之一，相當于LR中的每秒事務數，後面括号中的mean表示這是一個平均值

Time per request: 2961.449 [ms] (mean)

#最重要的名額之二，相當于LR中的平均事務響應時間，後面括号中的mean表示這是一個平均值

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

#每個連接配接請求實際運作時間的平均值

Transfer rate: 16866.07 [Kbytes/sec] received

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

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 483 1773.5 11 9052

Processing: 2 556 1459.1 255 11763

Waiting: 1 515 1459.8 220 11756

Total: 139 1039 2296.6 275 11843

#網絡上消耗的時間的分解，各項資料的具體算法還不是很清楚

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

50% 275

66% 298

75% 328

80% 373

90% 3260

95% 9075

98% 9267

99% 11713

100% 11843 (longest request)

#整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的使用者響

應時間小于275毫秒，66％的使用者響應時間小于298毫秒，最大的響應時間小于11843毫秒。對于并發請求，cpu實際上并不是同時處理的，而是按照

每個請求獲得的時間片逐個輪轉處理的，是以基本上第一個Time per request時間約等于第二個Time per

request時間乘以并發請求數。

總結：在遠端對web伺服器進行壓力測試，往往效果不理想（因為網絡延時過大），建議使用内網的另一台或者多台伺服器通過内網進行測試，這樣得出的資料，準确度會高很多。如果隻有單獨的一台伺服器，可以直接本地測試，比遠端測試效果要準确。

另外，每秒處理請求數和并發并不是一個概念，但它們之間有聯系：  

設平均響應時間為t(機關為毫秒), 并發量為c，每秒處理請求數為q，則：  

q = (1000/t) * c

就是這個關系；  

想要升高q，就隻有兩條路：1) 降低t 2) 升高c  

對于'1', 隻能靠優化代碼實作，隻能盡量做，往往提升有限；  

對于'2', 通常c與你伺服器程式的請求處理模型有關，如果你伺服器程式是“一個線程對應一個請求”的模式，那麼c的最大值就受制于你能支撐多少個線程；如果是“一個程序對應一個請求”的模式，那麼c的最大值則受制于最大程序數；

在升高c的過程中，不得不注意的一點是，線程/程序數越多，上下文切換、線程/程序排程開銷會增大，這會顯著間接地增大t的值進而不能讓q跟着c的值等比升高, 是以一味增大c通常也不會有好結果，最合适的c值應該根據實測試驗得出

另外，還有一種特殊情況：若業務決定了該伺服器提供的服務具有“小資料量、較長傳回時間”的特征，即這是一個不忙、但很慢的業務類型，那麼可以采用NIO模式提供服務，比如nginx預設就采用nio模式；  

在這種模式下，c值不再與線程/程序數相關，而僅僅與“socket連接配接數”相關，通常“socket連接配接數”可以非常大，在經過特殊配置的linux伺服器上，可以同時支撐百萬級别的socket連接配接數，在這種情況下c可以達到100w;  

在如此高的c值之下，就算t再大，也可以支撐出一個很高的q，同時真正的線程/程序數可以隻開到跟cpu核數一緻，以求最大化cpu使用率;  

當然這一切的前提是該業務具有“小資料量、較長傳回時間”的特征