服務器壓力測試 性能測試 AB、Webbench、Tsung

 原文：https://blog.csdn.net/Jerome_s/article/details/47030671

負載生成器是一些生成用於測試的流量的程序。它們能夠向你展現服務器在高負載的狀況下的性能，以及讓你可以找出服務器可能存在的問題。爲了獲得更加客觀和準確的數值，應該從遠程訪問、局域網訪問和本地等多個方面進行全方位的測試。通常用127.0.0.1進行本機測試。

 Apache Benchmark

        ab 命令會建立不少的併發訪問線程，模擬多個訪問者同時對某一 URL 進行訪問，可用來測試 Apache 的負載壓力，也能夠測試 Nginx、lighthttp、IIS 等其它 Web 服務器的壓力。

 

1. 安裝

 

        Unix 安裝：yum install httpd

 

        Windows安裝：下載  http://pan.baidu.com/s/1mifnlUS 

 

        在安裝目錄 bin下能夠看到 ab.exe。

2. 使用

        爲了不由於網絡緣由而致使服務器壓力測試結果不許確，通常能夠用 ab -n 100 -c 50 http://127.0.0.1/index.php 來測試本身服務器Web性能。全部 ab 命令的組成遵循此結構：   ab [options] [full path to web document] 。

        ab -n 1000 -c 10  http://www.qq.com/

       「-n」表示：每次請求數，默認不能超過1024個，「-c」表示：1個請求的併發鏈接數，默認最大不能超過50000

        

 

        可選標記

標記	描述
-A                   <username>:<password>	用於提供服務器身份驗證信息。 用戶名和密碼用「:」分隔。 發送的字符串採用base64編碼
-c <concurrency  number>	一次模擬的請求數。默認情 況下設置爲1。數量不得大於n值
-C cookie-name=value	可重複的標記，包含cookie信息
-d	隱藏「percentage served within XX[ms] table」

標記	描述
-e	要建立的.csv文件的路徑。該文件包 含運行的基準測試的結果，該結果分爲 兩列，即Percentage和Time in ms。建議 採用「gnuplot」文件
-g	要建立的「gnuplot」或TSV文件的路徑。 基準測試的輸出將保存到該文件中
-h	顯示要用於ab的選項列表
-H custom-header	採用字段值對形式發送有效標頭和請求
-i	執行HEAD請求，而不是默認的GET請求
-k	啓用Keep-Alive功能。容許經過一個 HTTP會話知足多個請求。默認狀況下， 該功能處於禁用狀態
-n requests	要執行的請求總數
-p POST-file	包含用於HTTP POST請求的數據的 文件路徑。內容應該包含由&分隔的鍵=值對
-P username:password	採用Base64編碼的字符串。字符串包含 基自己份驗證，以及由「:」分隔的用戶名和密碼
-q	執行多於100個請求時隱藏進度輸出
-s	使用https協議，而非默認的http協議 ——不建議這樣作
-S	隱藏中位數和標準誤差值
-t timelimit	指定了這個值之後，基準測試的時間 不會超過指定的值。默認狀況下無時間限制
-v verbosity-level	數值爲2及以上將打印警告和信息； 爲3將打印HTTP響應代碼；4及以 上將打印標頭信息
-V	顯示ab工具的版本號
-w	採用HTML表格打印結果
-x <table-attributes>	表示HTML屬性的字符串， 使用–w時將放置在<table>標記中
-X proxy[:port]	指定要使用的代理服務器。 代理端口是可選的
-y <tr-attributes>	表示HTML屬性的字符串， 使用–w時將放置在<tr>標記中
-z <td-attributes>	表示HTML屬性的字符串， 使用–w時將放置在<td>標記中

        響應描述

字段	描述	示　例　值
Concurrency Level	所進行的併發請求總數	1,2,3,…,n， 其中n爲任意數字
Time taken for tests	運行所花費的總時間	000.000秒
Complete requests	模擬的請求總數中已 完成的請求總數	1,2,3,…,n， 其中n爲任意數字

字段	描述	示　例　值
Failed requests	模擬的請求總數 中失敗的請求總數	1,2,3, …,n， 其中n爲任意數字
Write errors	使用寫入數據時 遇到的錯誤總數	1,2,3, …,n， 其中n爲任意數字
Non-2×× responses	未收到HTTP成功 響應的請求總數(200)	1,2,3,…,n， 其中n爲任意數字
Total transferred	整個模擬的響應中 傳輸的總數據， 大小包括標頭數據	725個字節
HTML transferred	整個模擬傳輸的內容 正文的總大小	137 199個字節
Requests per second	每秒支持的請求總數	5.68 [#/秒] （平均值）
Time per request	知足一個請求須要 花費的總時間	176.179毫秒
Time per request	知足全部併發請求 中的一個請求須要 花費的總時間	176.179毫秒
Transfer rate	每秒收到的字節總數（KB）	766.27 [KB/秒]

 

        HTML transferred、Requests per second 以及 Time per request 都是關鍵字段。根據這些數據，咱們能大概瞭解 Web 服務器的性能水平，這些字段使咱們可以大概瞭解Web服務器爲一個請求返回的數據量、Web服務器一秒能夠處理的請求總數以及一個請求成功地收到來自Web服務器的響應所花費的總時間。

        咱們的目標是成功下降 HTML transferred，提升 Requests per second 而且下降 Time per request 值。

其餘字段解釋

一、吞吐率（Requests per second）

        服務器併發處理能力的量化描述，單位是reqs/s，指的是在某個併發用戶數下單位時間內處理的請求數。某個併發用戶數下單位時間內能處理的最大請求數，稱之爲最大吞吐率。

        記住：吞吐率是基於併發用戶數的。這句話表明了兩個含義： 

        a、吞吐率和併發用戶數相關 

        b、不一樣的併發用戶數下，吞吐率通常是不一樣的 

        計算公式：總請求數/處理完成這些請求數所花費的時間，即 Request per second=Complete requests/Time taken for tests 。

        必需要說明的是，這個數值表示當前機器的總體性能，值越大越好。 

二、用戶平均請求等待時間（Time per request）

        計算公式：處理完成全部請求數所花費的時間/（總請求數/併發用戶數），即： Time per request=Time taken for tests/（Complete requests/Concurrency Level） 。

三、服務器平均請求等待時間（Time per request:across all concurrent requests）

        計算公式：處理完成全部請求數所花費的時間/總請求數，即： Time taken for/testsComplete requests 。

        能夠看到，它是吞吐率的倒數。 同時，它也等於用戶平均請求等待時間/併發用戶數，即 Time per request/Concurrency Level 。

        

        最後一個部分包含一個表，其中包含Connect、Processing、Waiting以及Total字段。這些字段告訴咱們請求在每一個過程狀態中所需的時間。咱們最感興趣的是Total字段及其最大、最小值列。這兩列提供響應一個請求所需花費的最長和最短期的數據。

 

 

Webbench

        Webbench 最多能夠模擬3萬個併發鏈接數來測試服務器壓力，能夠設置壓力測試時間和測試請求的成功率。

1. 安裝：

wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz  
tar zxvf webbench-1.5.tar.gz  
cd webbench-1.5  
make && make install  

若是在編譯webbench的時候，出現/bin/sh: ctags: command not found，以下所示

[root@webbench-1.5]# make  
cc -Wall -ggdb -W -O   -c -o webbench.o webbench.c  
webbench.c: In function ‘alarm_handler’:  
webbench.c:77: warning: unused parameter ’signal’  
cc -Wall -ggdb -W -O   -o webbench webbench.o  
ctags *.c  
/bin/sh: ctags: command not found  
make: [tags] Error 127 (ignored)  

是沒安裝ctags組件，使用yum -y install ctags,解決問題

若是安裝了ctags, 仍然報錯:

install -s webbench /usr/local/bin  
install -m 644 webbench.1 /usr/local/man/man1  
install: cannot create regular file `/usr/local/man/man1′: No such file or directory    

報錯：make: *** [install] Error 1

解決方法

mkdir -m 644 -p /usr/local/man/man1

2. 使用 

  webbench -c 1000 -t 10 http://www.qq.com/index.php

  -c是併發數 -t是運行測試時間，即10秒鐘內中以每次100個請求進行測試。

         這是運行Webbench測試結果，Speed顯示的是每分鐘響應請求數和每秒鐘傳輸數據量，Requests顯示的是成功請求數和失敗請求數。

        

        爲準確獲得服務器的承受壓力，測試時併發數可逐漸加大，如併發100時觀察一下網站負載是多少、打開頁面是否流暢，當網站打開緩慢時併發是多少、網站打不開時併發又是多少。

 

Tsung

        Tsung 是一款重型的（heavy-duty）、分佈式的、多協議測試工具。它每秒基本能夠產生 40,000 個請求，這絕對是咱們想要的工具。相似於 Jmeter，你能夠把一些行爲記錄下來在測試時運行，而且能夠測試大多數的協議。好比 SSL、HHTP、WebDAV、SOAP、PostgreSQL、MySQL、LDAP 和 Jabber/XMPP。與 Jmeter 不一樣的是，它沒有讓人感到迷茫的 GUI 設置，它僅有一個 XML 配置文件，和一些你選擇的分佈式節點的 SSH 密鑰。它的簡潔和效率對個人吸引力，徹底不亞於它的健壯性和可擴展性。我發現它是一個很強大的工具，在正確的配置下它能夠每秒產生百萬級的 HTTP 請求。

        除此以外，Tsung 還能夠在 HTML 上產生圖表以及輸入你的測試的詳細報告。

在 CentOS 6.2 上安裝 Tsung

        1. 首先，你要安裝（Erlang 須要的） EPEL 源。所以，在進行下一步以前要把它安裝好。安裝完後，繼續安裝你用來產生負載的每一個節點須要的包。若是你尚未在節點之間創建無密碼 SSH 密鑰（passwordless SSH key），那麼請建之。

1	yum -y  install  erlang perl perl-RRD-Simple.noarch perl-Log-Log4perl-RRDs.noarch gnuplot perl-Template-Toolkit firefox

        2. 從 Github 或者 Tsung 的官網上下載最新的 Tsung。

1	wget http: //tsung .erlang-projects.org /dist/tsung-1 .4.2. tar .gz

        3. 解壓而且編譯

1 2 3

tar  zxfv  tsung-1.4.2. tar .gz cd  tsung-1.4.2 . /configure  &&  make  &&  make  install

使用

        把示例配置複製到 ~/.tsung 目錄裏。這是 Tsung 的配置文件和日誌文件的存放地方（目錄不存在建立便可）。

1	cp   /usr/share/doc/tsung/examples/http_simple .xml  /root/ .tsung /tsung .xml

        你能夠根據你的需求去編輯這個配置文件，或者使用個人配置文件。通過大量的嘗試以及失敗後，我目前的配置文件在使用 7 個分佈式節點時能夠每秒產生 5 百萬個 HTTP 請求。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

<? xml version = "1.0" ?> <!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd"> < tsung loglevel = "notice" version = "1.0" >   < clients > < client host = "localhost" weight = "1" cpu = "10" maxusers = "40000" > < ip value = "192.168.122.2" /> </ client > < client host = "loadnode1" weight = "1" cpu = "9" maxusers = "40000" > < ip value = "192.168.122.2" /> </ client > < client host = "loadnode2" weight = "1" maxusers = "40000" cpu = "8" > < ip value = "192.168.122.3" /> </ client > < client host = "loadnode3" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.21" /> </ client > < client host = "loadnode4" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.11" /> </ client > < client host = "loadnode5" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.12" /> </ client > < client host = "loadnode6" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.13" /> </ client > < client host = "loadnode7" weight = "1" maxusers = "40000" cpu = "9" > < ip value = "192.168.122.14" /> </ client > </ clients >   < servers > < server host = "192.168.122.10" port = "80" type = "tcp" /> </ servers >   < load > < arrivalphase phase = "1" duration = "10" unit = "minute" > < users maxnumber = "15000" arrivalrate = "8" unit = "second" /> </ arrivalphase >   < arrivalphase phase = "2" duration = "10" unit = "minute" > < users maxnumber = "15000" arrivalrate = "8" unit = "second" /> </ arrivalphase >   < arrivalphase phase = "3" duration = "30" unit = "minute" > < users maxnumber = "20000" arrivalrate = "3" unit = "second" /> </ arrivalphase >   </ load >   < sessions > < session probability = "100" name = "ab" type = "ts_http" > < for from = "1" to = "10000000" var = "i" > < request > < http url = "/test.txt" method = "GET" version = "1.1" /> </ request > </ for > </ session > </ sessions > </ tsung >

 

        剛開始的時候有不少東西要理解，但你一旦理解了它們後就會變得很簡單。

        <client> 只是簡單地指定了運行 Tsung 的主機。你能夠指定 Tsung 使用的 IP 和 CPU 的最大數。你可使用 maxusers 設置節點可以模擬的用戶數量上限。每個用戶都會執行咱們以後定義的操做。

        <servers> 指定了你要測試的 HTTP 服務器。咱們可使用這個選項去測試一個 IP 集羣，或者一個單一的服務器。

        <load> 定義了咱們的模擬用戶將會在何時「到達」咱們的網站。以及它們達到的有多快。

        <arrivalphase> 在持續了 10 分鐘的第一個階段裏，以 每秒 8 個用戶的速率到達了 15,000 個用戶。

        <arrivalphase phase=」1″ duration=」10″ unit=」minute」>

        <users maxnumber=」15000″ arrivalrate=」8″ unit=」second」/>

         這裏還有兩個 arrivalphases，它們的用戶都以一樣的方式達到。

         這些 arrivalphases 一塊兒組成了一個 <load>，它控制了咱們能夠每秒產生多少個請求。

        <session> 這部分定義了一旦這些用戶達到了你的網站，它們將會執行什麼動做。

        probability 容許你定義用戶可能會作的隨機事件。有時他們可能點擊這裏，有時他們可能點擊那裏。全部的Probability 加起來必定要等於 100% 。

        在上面的配置裏，用戶只作一件事，因此它的 probability 等於 100% 。

        <for from=」1″ to=」10000000″ var=」i」> 這就是用戶在 100% 的時間裏作的事情。它們循環遍歷 10,000,000 次而且 <request> 一個網頁：/test.txt 。

        這個循環結構容許咱們使用少許的用戶鏈接去獲取比較大的每秒請求數量。

        一旦你已經很好地理解了它們，你就能夠建立一個便利的別名，去快速觀察 Tsung 報告。

vim ~/.bashrc alias treport= "/usr/lib/tsung/bin/tsung_stats.pl; firefox report.html"

1	source ~/.bashrc

        而後啓動 Tsung

1 2 3

[root@loadnode1 ~] tsung start Starting Tsung "Log directory is: /root/.tsung/log/20120421-1004"

        結束後觀察報告

1 2	cd /root/ .tsung /log/20120421-1004 treport #生成圖片報告

        把20120421-1004經過 ftp下載下來就可使用查看了，以下圖

        

使用 Tsung 去規劃你的集羣構造

        如今咱們擁有了一個足夠強大的負載測試工具，咱們能夠規劃餘下的集羣構造了：

        1. 使用 Tsung 去測試一個單一的 HTTP 服務器。獲取一個基本的基準。

        2. 對 web 服務器進行調優，按期使用 Tsung 進行測試提升性能。

        3. 對這些系統的 TCP 套接字進行調優，獲取最佳的網絡性能。再來一次，測試，測試，不停地測試。

        4. 構造 LVS 集羣，它包含了這些充分調優過的 web 服務器。

        5. 使用 Tsung IP 集羣對 LVS 進行壓力測試。