網站性能壓力測試是服務器網站性能調優過程中必不可缺少的一環。只有讓服務器處在高壓情況下，才能真正體現出軟件、硬件等各種設置不當所暴露出的問題。
性能測試工具目前最常見的有以下幾種：ab、http_load、webbench、siege。
ab是apache自帶的壓力測試工具。ab非常實用，它不僅可以對apache服務器進行網站訪問壓力測試，也可以對或其它類型的服務器進行壓力測試。比如nginx、tomcat、IIS等。
一、ab的原理
ab是apachebench命令的縮寫。
ab的原理：ab命令會創建多個并發訪問線程，模擬多個訪問者同時對某一URL地址進行訪問。它的測試目標是基于URL的，因此，它既可以用來測試apache的負載壓力，也可以測試nginx、lighthttp、tomcat、IIS等其它Web服務器的壓力。
ab命令對發出負載的計算機要求很低，它既不會占用很高CPU，也不會占用很多內存。但卻會給目標服務器造成巨大的負載，其原理類似CC攻擊。自己測試使用也需要注意，否則一次上太多的負載。可能造成目標服務器資源耗完，嚴重時甚至導致死機。
二、ab的安裝
如果不想安裝apache但是又想使用ab命令的話，我們可以直接安裝apache的工具包httpd-tools。
#yum -y install httpd-tools
查看ab是否安裝成功
#ab -V
三、ab參數說明
-n 在測試會話中所執行的請求個數。默認時，僅執行一個請求。
-c 一次產生的請求個數。默認是一次一個。
-t 測試所進行的最大秒數。其內部隱含值是-n 50000，它可以使對服務器的測試限制在一個固定的總時間以內。默認時，沒有時間限制。
-p 包含了需要POST的數據的文件。
-P 對一個中轉代理提供BASIC認證信任。用戶名和密碼由一個:隔開，并以base64編碼形式發送。無論服務器是否需要(即, 是否發送了401認證需求代碼)，此字符串都會被發送。
-T POST數據所使用的Content-type頭信息。
-v 設置顯示信息的詳細程度-4或更大值會顯示頭信息，3或更大值可以顯示響應代碼(404,200等),2或更大值可以顯示警告和其他信息。
-V 顯示版本號并退出。
-w 以HTML表的格式輸出結果。默認時，它是白色背景的兩列寬度的一張表。
-i 執行HEAD請求，而不是GET。
-X 對請求使用代理服務器。
-C 對請求附加一個Cookie:行。其典型形式是name=value的一個參數對，此參數可以重復。
-H 對請求附加額外的頭信息。此參數的典型形式是一個有效的頭信息行，其中包含了以冒號分隔的字段和值的對(如,”Accept-Encoding:zip/zop;8bit”)。
-A 對服務器提供BASIC認證信任。用戶名和密碼由一個:隔開，并以base64編碼形式發送。無論服務器是否需要(即,是否發送了401認證需求代碼)，此字符串都會被發送。
-h 顯示使用方法。
-d 不顯示“percentage served within XX [ms] table”的消息(為以前的版本提供支持)。
-e 產生一個以逗號分隔的(CSV)文件，其中包含了處理每個相應百分比的請求所需要(從1%到100%)的相應百分比的(以微妙為單位)時間。由于這種格式已經“二進制化”，所以比‘gnuplot’格式更有用。
-g 把所有測試結果寫入一個‘gnuplot’或者TSV(以Tab分隔的)文件。此文件可以方便地導入到Gnuplot,IDL,Mathematica,Igor甚至Excel中。其中的第一行為標題。
-i 執行HEAD請求，而不是GET。
-k 啟用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求。默認時，不啟用KeepAlive功能。
-q 如果處理的請求數大于150，ab每處理大約10%或者100個請求時，會在stderr輸出一個進度計數。此-q標記可以抑制這些信息。
四、ab性能指標
在進行性能測試過程中有幾個指標比較重要：
1、吞吐率（Requests per second）
服務器并發處理能力的量化描述，單位是reqs/s，指的是在某個并發用戶數下單位時間內處理的請求數。某個并發用戶數下單位時間內能處理的最大請求數，稱之為最大吞吐率。
吞吐率是基于并發用戶數的。這句話代表了兩個含義：
a、吞吐率和并發用戶數相關
b、不同的并發用戶數下，吞吐率一般是不同的
計算公式：總請求數/處理完成這些請求數所花費的時間，即
Request per second=Complete requests/Time taken for tests
這個數值表示當前機器的整體性能，值越大越好。
2、并發連接數（The number of concurrent connections）
并發連接數指的是某個時刻服務器所接受的請求數目，簡單的講，就是一個會話。
3、并發用戶數（Concurrency Level）
要注意區分這個概念和并發連接數之間的區別，一個用戶可能同時會產生多個會話，也即連接數。在HTTP/1.1下，IE7支持兩個并發連接，IE8支持6個并發連接，FireFox3支持4個并發連接，所以相應的，我們的并發用戶數就得除以這個基數。
4、用戶平均請求等待時間（Time per request）
計算公式：處理完成所有請求數所花費的時間/（總請求數/并發用戶數），即：
Time per request=Time taken for tests/（Complete requests/Concurrency Level）
5、服務器平均請求等待時間（Time per request:across all concurrent requests）
計算公式：處理完成所有請求數所花費的時間/總請求數，即：
Time taken for/testsComplete requests
可以看到，它是吞吐率的倒數。
同時，它也等于用戶平均請求等待時間/并發用戶數，即
Time per request/Concurrency Level
五、ab實際使用
同時處理,500個請求并運行3000次index.php文件。（并發用戶500，請求總數3000）
#ab -c 500 -n 3000 http://www.ilinux.io/pma/index.php
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking www.ilinux.io (be patient)
Completed 300 requests
Completed 600 requests
Completed 900 requests
Completed 1200 requests
Completed 1500 requests
Completed 1800 requests
Completed 2100 requests
Completed 2400 requests
Completed 2700 requests
Completed 3000 requests
Finished 3000 requests
Server Software: nginx/1.10.2 #平臺nginx版本1.10.2
Server Hostname: www.ilinux.io #服務器主機名
Server Port: 80 #服務器監聽端口
Document Path: /pma/index.php #測試的頁面 文檔
Document Length: 8713 bytes #文檔大小
Concurrency Level: 500 #并發數
Time taken for tests: 272.160 seconds #測試所需的時間
Complete requests: 3000 #完成的請求數
Failed requests: 1753 #失敗的請求數
(Connect: 0, Receive: 0, Length: 1753, Exceptions: 0)
Write errors: 0
Non-2xx responses: 1737
Total transferred: 13402041 bytes #整個場景中的網絡傳輸量
HTML transferred: 11276078 bytes #整個場景中的HTML內容傳輸量
Requests per second: 11.02 [#/sec] (mean) #相當于LR中的每秒事務數 ，后面括號中的mean表示這是一個平均值
Time per request: 45360.006 [ms] (mean) #相當于LR中的平均事務響應時間 ，后面括號中的mean表示這是一個平均值
Time per request: 8.189 [ms] (mean, across all concurrent requests)
Time per request: 90.720 [ms] (mean, across all concurrent requests)
Transfer rate: 48.09 [Kbytes/sec] received 平均每秒網絡上的流量，可以幫助排除是否存在網絡流量過大導致響應時間延長的問題
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 11 26.4 0 114
Processing: 175 36462 28236.2 60000 112596
Waiting: 42 35734 27999.6 60000 92176
Total: 175 36474 28227.1 60000 112597
Percentage of the requests served within a certain time (ms)
50% 60000
66% 60002
75% 60008
80% 60020
90% 63009
95% 67044
98% 91072
99% 91134
100% 112597 (longest request)
整個場景中所有請求的響應情況。在場景中每個請求都有一個響應時間，其中50％的用戶響應時間小于1093毫秒，60％的用戶響應時間小于1247 毫秒，最大的響應時間小于7785 毫秒。
由于對于并發請求，cpu實際上并不是同時處理的，而是按照每個請求獲得的時間片逐個輪轉處理的，所以基本上第一個Time per request時間約等于第二個Time per request時間乘以并發請求數。
原創文章，作者：Linux.rookie，如若轉載，請注明出處：http://www.www58058.com/82307
