[技術博客]幾種網站壓力測試工具調研與使用

時間 2019-11-20

原文原文鏈接

[技術博客]幾種網站壓力測試工具調研與使用

咱們在beta階段對於網站訪問作了很多優化工做，所以打算在本階段尾聲時對網站作了一個簡單的壓力測試，進而估算一下網站如今的併發量及處理能力。所以，咱們對現有較流行的幾種網絡壓力測試工具進行了簡單調研並嘗試部署使用。html

[技術博客]幾種網站壓力測試工具調研與使用

1. 在線網站

有一些網站提供了在線壓力測試功能，例如騰訊提供的 wetest 壓測大師, Nice tool, load impact, Post Json, PostMan等。咱們也嘗試使用了其中的一些，就使用上來講比較簡單，可是在一些特殊極端狀況下不是十分理想。python

1.1. 優點

通過咱們的嘗試，咱們認爲在線網站主要有如下優點linux

配置簡單 使用在線網站不須要本身在本地搭載環境，編寫代碼，並有一個較完善的UI界面。nginx
功能多 以wetest爲例，能夠提供監控核心性能指標如TPS、響應時間CPU、內存、磁盤IO、網卡負載、壓力機性能監測等（需求騰訊雲）web
結果展現直觀 上述大部分網站均可以直接以圖表的形式顯示結果，直觀而且能夠直接在展現中使用apache

1.2. 缺陷

併發限制 在線網站每每有最大併發限制，例如上述網站未登陸的狀況下都限制最大併發10~50。wetest，nicetool能夠經過註冊的方式增長併發限制，然而註冊過程較繁瑣，須要提供證實材料。windows
可定製化較低 很容易理解，在線網站測試的可定製化程度必定比本身寫代碼要低。bash
連接速度問題 在作實際測試是，咱們固然但願測試的是服務器的性能而不是網絡質量。所以，使用網站的結果可能會沒有直接在服務器上部署測試來的準確。服務器

1.3. 測試結果樣例

這裏咱們以nicetool爲例，執行50併發，100請求的測試，結果以下：網絡

Summary:
  Total:    1.3244 secs
  Slowest:  0.4565 secs
  Fastest:  0.1701 secs
  Average:  0.2889 secs
  Requests/sec: 151.0075
  

Response time histogram:
  0.170 [1]     |
  0.199 [88]    |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.227 [3]     |■
  0.256 [1]     |
  0.285 [0]     |
  0.313 [0]     |
  0.342 [36]    |■■■■■■■■■■■■■■■■
  0.371 [21]    |■■■■■■■■■■
  0.399 [0]     |
  0.428 [14]    |■■■■■■
  0.456 [36]    |■■■■■■■■■■■■■■■■


Latency distribution:
  10% in 0.1722 secs
  25% in 0.1751 secs
  50% in 0.3367 secs
  75% in 0.4204 secs
  90% in 0.4365 secs
  95% in 0.4415 secs
  99% in 0.4536 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0196 secs, 0.1701 secs, 0.4565 secs
  DNS-lookup:   0.0031 secs, 0.0000 secs, 0.0131 secs
  req write:    0.0001 secs, 0.0000 secs, 0.0027 secs
  resp wait:    0.2689 secs, 0.1699 secs, 0.3761 secs
  resp read:    0.0003 secs, 0.0001 secs, 0.0049 secs

Status code distribution:
  [200] 200 responses

2. 測試工具

除了在線網站，咱們也調研並使用了一些其它工具，包括 ab, pylot, siege等。下面作一下簡單介紹，基本按照推薦順序。

2.1. ab

ab 的全稱是apache bench，是由Apache提供的一款簡單高效的測試工具，支持windows和linux等。

2.1.1. 使用方法

首先須要下載Apache，對於windows，cmd進入安裝目錄的BIN文件夾下就能夠執行ab了。對於Linux，通常能夠經過安裝Apache服務解決。

ab包括如下參數：

-n 執行的請求數量
-c 併發請求個數
-t 測試所進行的最大秒數
-p 包含了須要POST的數據的文件
-T POST數據所使用的Content-type頭信息
-k 啓用HTTP KeepAlive功能，即在一個HTTP會話中執行多個請求，默認時，不啓用KeepAlive功能

一個簡單的例子是

ab -n 100 -c 100 http://www.baidu.com/

2.1.2. 測試結果

咱們使用

ab -n 100 -c 100 https://ratemycourse.tk/

進行了測試，測試結果以下:

Server Software:        cloudflare
Server Hostname:        ratemycourse.tk
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-CHACHA20-POLY1305,256,256
TLS Server Name:        ratemycourse.tk

Document Path:          /
Document Length:        6856 bytes

Concurrency Level:      100
Time taken for tests:   3.153 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      732100 bytes
HTML transferred:       685600 bytes
Requests per second:    31.72 [#/sec] (mean)
Time per request:       3153.013 [ms] (mean)
Time per request:       31.530 [ms] (mean, across all concurrent requests)
Transfer rate:          226.75 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      489  632 130.8    611    1232
Processing:   167  412 359.8    347    2159
Waiting:      164  223  86.2    193     817
Total:        695 1044 405.5    927    3133

Percentage of the requests served within a certain time (ms)
  50%    927
  66%   1029
  75%   1078
  80%   1154
  90%   1586
  95%   1895
  98%   2818
  99%   3133
 100%   3133 (longest request)

2.1.3. 優點與缺陷

ab提供的測試結果內容較多，十分完整，包括鏈接成功數，響應時間等多種內容並作了簡單分析，足夠使用。主要缺點是不能監控，沒有圖形化結果。ab好像是單核的，所以高併發時可能形成測試瓶頸。另外我服務器上已經使用了Nginx做爲webserver，再安裝Apache等還須要處理一些衝突問題。

2.2. siege

siege 是一個十分經常使用的開源的web服務壓力測試工具，能夠模擬數千併發的請求，並給出一個簡單的統計。siege的安裝使用很是簡單，下以Ubuntu/Debian爲例。

2.2.1. 安裝siege

siege能夠經過編譯源碼與apt兩種方式安裝，須要注意的是官網連接不是很穩定，雖然壓縮包大小僅有511K可是依然須要代理訪問，所以更推薦使用apt安裝。

源碼安裝的方式以下：

wget http://download.joedog.org/siege/siege-latest.tar.gz
tar -zxvf siege-latest.tar.gz
cd siege-4.0.4/
./configure
make
make install

sudo apt install siege

2.2.2. siege簡單教程

咱們摘錄了這篇文章中介紹用法的部分。

-C,或–config 在屏幕上打印顯示出當前的配置,配置是包括在他的配置文件$HOME/.siegerc中,能夠編輯裏面的參數,這樣每次siege 都會按照它運行.
-v 運行時能看到詳細的運行信息
-c n,或–concurrent=n 指定併發的用戶個數，-c 200指定併發數200。模擬有n個用戶在同時訪問,n不要設得太大,由於越大,siege 消耗本地機器的資源越多
-i,–internet 隨機訪問urls.txt中的url列表項,以此模擬真實的訪問狀況(隨機性),當urls.txt存在是有效。默認爲urls.txt列表從上到下來壓。
-d n,–delay=n hit每一個url之間的延遲,在0-n之間
-r n,–reps=n 重複運行測試n次,不能與-t同時存在
-t n,–time=n 持續時間。即測試持續時間。默認是分鐘。例: -t10S,(10秒) -t5M,(5分鐘) -t1H,(1小時)
-l 運行結束,將統計數據保存到日誌文件中siege .log,通常位於/usr/local/var/siege .log中,也可在.siegerc中自定義
-R SIEGERC,–rc=SIEGERC 指定用特定的siege 配置文件來運行,默認的爲$HOME/.siegerc
-f FILE, –file=FILE 指定用特定的urls文件運行siege ,默認爲urls.txt,位於siege 安裝目錄下的etc/urls.txt
-u URL,–url=URL 測試指定的一個URL,對它進行」siege 「,此選項會忽略有關urls文件的設定
-b 進行壓力測試，不進行延時。
-A, --user-agent=「text」設置請求的User-Agent

使用以上命令基本能夠知足大部分測試需求了。以咱們的測試爲例，咱們考察了1000併發下的網站工做狀況，使用了以下命令：

siege -c 100  https://ratemycourse.tk -i -b

2.2.3. 測試結果

簡單測試結果以下：

Lifting the server siege...
Transactions:                    100 hits
Availability:                 100.00 %
Elapsed time:                   2.30 secs
Data transferred:               0.23 MB
Response time:                  1.29 secs
Transaction rate:              45.65 trans/sec
Throughput:                     0.10 MB/sec
Concurrency:                   58.68
Successful transactions:         100
Failed transactions:               0
Longest transaction:            1.53
Shortest transaction:           1.04

2.2.4. 優點與缺點

siege安裝方便，比起ab，不須要解決與nginx可能的衝突的問題。siege的測試速度直觀上比ab更快。siege提供的信息要略少一些，不過對於簡單分析依然足夠。

另外siege有一個小坑：siege的最大併發連接默認值是255，須要手動到配置文件中修改。siege在WSL和部分macOS上啓動會失敗，建議使用虛擬機或完整的Linux環境。

2.3. pylot

pylot是一個python寫的測試工具，支持命令行與圖形界面，支持生成圖表，配置簡單易用。其實pylot是我最先嚐試的工具，由於簡介博客說它基於python，又能夠畫圖。

然而簡介老是美好的，現實老是殘酷的。簡單來講，就目前請不要再試圖使用或推薦pylot了。

首先是官網進不去。咱們在博客的介紹裏找到了所謂的官網：www.pylot.org，然而實際上這個網站如今是emmm，在線發牌。
幸運的是，咱們還有web archive這個老朋友。emmm，然而看上去最後更新的版本2009/07/06的。另外它好像只支持python2，我也不知道有沒有人在繼續維護。

就結論來講，我好像浪費了一小時試圖搞定這個玩意。

2.4. 簡單總結

總的來講，這些測試工具比起網站能夠本身部署，能夠本身定製功能。直接部署到服務器上或者與服務器有較高鏈接速率的服務器上（例如同一局域網）能夠最大限度避免網絡質量致使的偏差。相較於在線測試網站，咱們也能夠自定義更大的鏈接數，測試更高的併發。

3. 造輪子本身寫腳本

除了使用上面的工具以外，咱們還可使用本身寫的一些其餘腳本實現更多功能。利用python的request庫，簡單的就能夠模擬一個請求。本身寫的腳本每每能夠實現更多特殊的功能，可是他們一樣也會面臨一些問題，例如魯棒性，異常處理完整性，測試的公平準確性等問題。例如，下面的測試代碼模擬了連續25秒，每秒請求200次的壓力測試。

import requests
import threading
import time

class thread1(threading.Thread):
    count200=0
    count502=0
    count504=0
    count500=0
    countelse=0
    def __init__(self, threadID, name):
        threading.Thread.__init__(self)
        self.threadID = threadID
        self.name = name
    def run(self):
        time.sleep(50)
        code = requests.get(YOUR_WEB_SITE).status_code
        if int(code)==200:
            thread1.count200+=1
        elif int(code)==502:
            thread1.count502+=1
        elif int(code)==504:
            thread1.count504+=1
        elif int(code)==500:
            thread1.count500+=1
        else:
            thread1.countelse+=1

if __name__=="__main__":
    threads=[]
    for i in range(5000):
        thread=thread1(i, "Thread-{}".format(i))
        threads.append(thread)
    for i in threads:
        i.start()
        time.sleep(0.005)
    for i in threads:
        i.join()
    print(thread1.count200,thread1.count502,thread1.count504,thread1.count500,thread1.countelse)