網站性能測試指標及網站壓力測試

1. 通常衡量網站性能有哪些指標？

性能指標主要有響應時間，吞吐量，併發量，性能計數器。

1）響應時間

指應用執行一個操做須要的時間，即從發出請求到最後收到響應數據所須要的時間。

系統經常使用操做響應時間表

操做	響應時間
打開一個網站	幾秒
數據庫查詢一條記錄（有索引）	十幾毫秒
機械磁盤一次尋址定位	4毫秒
從機械磁盤順序讀取1M數據	2毫秒
從SSD磁盤順序讀取1M數據	0.3毫秒
從遠程分佈式換成Redis讀取一個數據	0.5毫秒
從內存讀取1M數據	十幾微秒
Java程序本地方法調用	幾微秒
網絡傳輸2Kb數據	1微秒

實踐中一般採用的辦法是重複請求，好比一個請求操做重複執行1萬次，測試一萬次執行的總響應時間之和，而後除以1萬，就獲得單次請求的響應時間。

2）吞吐量

指單位時間內系統處理的請求數量，體現系統的總體處理能力。對於網站，可用「請求數/秒」、「頁面數/秒」或「訪問人數/天」、「處理業務數/小時」等來衡量。重要指標有TPS(每秒處理的事物數)、QPS(每秒查詢的請求數)、HPS（每秒HTTP請求數）等。

3）併發量

指系統可以同時處理的請求的數目，這個數字反映了系統的負載性能。對於網站而言，併發數指網站用戶同時提交請求的用戶數目。

4）性能計數器

描述服務器或操做系統性能的一些數據指標。如System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡I/O等使用狀況。經過對這些指標設置報警閾值，當監控系統發現性能計數器超過閾值時，就向開發人員和運維報警，及時發現異常並處理。

 

2. 怎麼測試網站性能？

性能測試具體能夠細分爲性能測試、負載測試、壓力測試、穩定性測試。

1）性能測試

以系統設計初期規劃的性能指標爲預期目標，對系統不斷施加壓力，驗證系統在資源可接受範圍內是否能達到預期。

2）負載測試

對系統不斷增長併發請求以增長系統壓力，直到系統的某項或多項性能指標達到安全臨界值，這時繼續對系統施加壓力，系統的處理能力不但不會提升，反而會降低。

3）壓力測試

超過安全負載的狀況下，對系統施加壓力，直到系統崩潰或不能再處理任何請求，以此得到系統最大壓力承受能力。

4）穩定性測試

被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載必定業務壓力，使系統運行一段較長時間，以此檢驗系統是否穩定。

 

3. 怎麼進行壓力測試？

壓力測試工具備http_load、apache ab、siege。

1）http_load

下載：http://acme.com/software/http_load/（點擊Fetch the software便可）

安裝：

tar zxvf http_load-09Mar2016.tar.gz
cd http_load-09Mar2016
make
sudo make install

注：遇到了Error1，但不影響使用。

（2017.9.12整理筆記時，又嘗試了一下，發現能夠用Homebrew安裝http_load，當時怎麼沒想到用Homebrew安裝啊。。。😑）

命令格式：

http_load -p 併發訪問進程數 -f 訪問總數 須要訪問的URL文件 http_load -r 每秒訪問頻率 -s 訪問時間 須要訪問的URL文件 // 參數說明：一般參數pf一塊兒使用，參數rs一塊兒使用。
-parallel 簡寫 -p ：併發的用戶進程數。 -fetches 簡寫 -f ： 總計的訪問次數。 -rate 簡寫 -r ： 每秒的訪問頻率。 -seconds 簡寫 -s ：總計的訪問時間。

使用：

新建一個urls.txt，urls.txt 是一個url 列表，每一個url 單獨的一行。

在文件中加入一行：http://www.acme.com/software/http_load/

① 測試網站是否能承受住預期的訪問壓力

執行http_load -rate 5 -seconds 10 urls.txt，含義爲在10秒內保持必定的頻率訪問目標url。

結果分析：

48 fetches, 6 max parallel, 253264 bytes, in 10.0031 seconds
// 說明在上面的測試中運行了48個請求，最大的併發進程數是6，總計傳輸的數據是253264bytes，運行的時間是10.0031秒
5276.33 mean bytes/connection
// 說明每次鏈接平均傳輸的數據量是5276.33bytes。253264/48=5276.33
4.7985 fetches/sec, 25318.5 bytes/sec
// 說明每秒的響應請求爲4.7985個，每秒傳遞的數據爲25318.5 bytes
msecs/connect: 251.601 mean, 1493.45 max, 26.176 min
// 說明每次鏈接的平均響應時間是251.601 毫秒，最大的響應時間1493.45 毫秒，最小的響應時間26.176 毫秒
msecs/first-response: 232.251 mean, 796.783 max, 39.402 min
// 說明每次鏈接的平均返回時間是232.251 毫秒，最大的響應時間796.783 毫秒，最小的響應時間39.402 毫秒
HTTP response codes:
code 200 -- 48
// 說明HTTP返回碼是200，一共48次。
 
主要參考fetches/sec、msecs/connect數值，
前者對應QPS，表示每秒的響應請求數，後者對應response time，表示每一個鏈接的響應時間。

 

② 測試網站每秒所能承受的平均訪問量

執行http_load -parallel 5 -fetches 1000 urls.txt，含義爲同時使用5個進程，隨機訪問urls.txt中的網址列表，總共訪問1000次。

結果分析：

1000 fetches, 5 max parallel, 2。607e+06 bytes, in 328.806 seconds
2607 mean bytes/connection
3.04131 fetches/sec, 7928.69 bytes/sec
msecs/connect: 772.326 mean, 19478.3 max, 219.936 min
msecs/first-response: 830.46 mean, 10006.4 max, 237.957 min
HTTP response codes:
code 200 — 1000
 
從上面結果看，目標網站僅僅可以承受每秒3次的訪問，不夠強壯。

2）apache ab

ab是Apache自帶的壓力測試工具，能夠用which ab查看ab命令所在的目錄。

命令格式：

ab -c 併發數 -n 請求數 URL
// 參數說明：
-n 在測試會話中所執行的請求個數。默認時，僅執行一個請求
-c 一次產生的請求個數。默認是一次一個。
-t 測試所進行的最大秒數。其內部隱含值是-n 50000。它可使對服務器的測試限制在一個固定的總時間之內。默認時，沒有時間限制。

使用：

執行ab -n 100 -c 100 http://127.0.0.1/test/test.php，含義爲同時處理100個請求並運行100次test.php，模擬100個併發用戶，對一個頁面發送100個請求。

結果分析：

Server Software: Apache/2.4.23 // 服務器名稱，apache 版本2.4.23
Server Hostname: 127.0.0.1 // 服務器主機名
Server Port: 80 // 服務器端口
 
Document Path: /test/test.php // 請求的URL中的根絕對路徑，經過該文件的後綴名，咱們通常能夠了解該請求的類型
Document Length: 54 bytes // HTTP響應數據的正文長度
 
Concurrency Level: 100 // 併發用戶數
Time taken for tests: 0.085 seconds // 整個測試持續的時間，全部這些請求被處理完成所花費的總時間
Complete requests: 100 // 完成的請求數量
Failed requests: 0 // 失敗的請求數量
Total transferred: 25600 bytes // 全部請求的響應數據長度總和，包括每一個HTTP響應數據的頭信息和正文數據的長度
HTML transferred: 5400 bytes // 全部請求的響應數據中正文數據的總和，也就是減去了Total transferred中HTTP響應數據中的頭信息的長度。
Requests per second: 1177.59 [#/sec] (mean) // 吞吐率，計算公式：Complete requests/Time taken for tests。至關於每秒事務數，後面括號中的 mean 表示這是一個平均值。吞吐率越高，服務器性能越好。
Time per request: 84.919 [ms] (mean) // 用戶平均請求等待時間，計算公式：Time token for tests/（Complete requests/Concurrency Level）。至關於平均事務響應時間 ，後面括號中的 mean 表示這是一個平均值。
Time per request: 0.849 [ms] (mean, across all concurrent requests) // 服務器平均請求等待時間，計算公式：Time taken for tests/Complete requests，正好是吞吐率的倒數。也能夠這麼統計：Time per request/Concurrency Level。
Transfer rate: 294.40 [Kbytes/sec] received //這些請求在單位時間內從服務器獲取的數據長度，即平均每秒網絡上的流量，計算公式：Total trnasferred/ Time taken for tests，這個統計很好的說明服務器的處理能力達到極限時，其出口寬帶的需求量，能夠幫助排除是否存在網絡流量過大致使響應時間延長的問題。
 
Connection Times (ms)
min mean[+/-sd] median max
Connect: 1 2 0.4 2 3
Processing: 6 44 23.4 46 81
Waiting: 6 44 23.5 46 81
Total: 8 46 23.1 47 82
// 網絡上消耗的時間的分解
Percentage of the requests served within a certain time (ms)
50% 47
66% 60
75% 66
80% 72
90% 76
95% 80
98% 82
99% 82
100% 82 (longest request)
// 這部分數據用於描述每一個請求處理時間的分佈狀況，好比以上測試，66%的請求處理時間都不超過60ms，這個處理時間是指前面的Time per request，即對於單個用戶而言，平均每一個請求的處理時間。

併發請求量稍微高一點(200,300以上)就會報apr_socket_recv: Connection reset by peer 的錯。

3）siege

安裝：從http://download.joedog.org/siege/下載的siege包make && make install 失敗，改用Homebrew安裝

命令格式：

siege -c 併發數 -t 運行測試時間 URL
siege -c 併發量 -r 重複次數 -f URL
// 參數說明：-r和-t通常不一樣時使用
-c 200 指定併發數200
-r 5 指定測試的次數5
-t 5 持續測試5分鐘，-t若是不帶單位，默認是分鐘，s表示秒。
-f urls.txt 指定url的文件
-i internet的簡寫，隨機發送url
-b 請求無需等待 delay=0

使用：

執行siege -c 10 -r 5 -f urllist.txt，含義爲10個併發對urllist文件發送請求5次。

（-----中間滾屏略-----）

結果分析：

Transactions:                      300 hits           // 總共測試次數，完成300次處理
Availability:                   100.00 %              // 成功次數百分比，100.00 % 成功率
Elapsed time:                    31.36 secs           // 總共用時31.36秒
Data transferred:                 0.43 MB             // 共數據傳輸0.43 MB
Response time:                    0.90 secs           // 響應用時0.90秒
Transaction rate:                 9.57 trans/sec      // 平均每秒完成 9.57 次處理
Throughput:                       0.01 MB/sec         // 吞吐率，平均每秒傳送數據
Concurrency:                      8.62                // 最高併發數
Successful transactions:           250                // 成功請求數
Failed transactions:                 0                // 失敗請求數
Longest transaction:              3.66                // 每次傳輸所花最長時間
Shortest transaction:             0.50                // 每次傳輸所花最短期