轉載至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
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)
//-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 requestsServer Software: Apache/2.2.15
Server Hostname: 192.168.80.157
Server Port: 80Document 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利用率;
當然這一切的前提是該業務具有“小數據量、較長返回時間”的特徵