bin AC gdb 可能 mpp body lar share dir

原文：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 值。 其他字段解釋 1、吞吐率（Requests per second） 服務器並發處理能力的量化描述，單位是reqs/s，指的是在某個並發用戶數下單位時間內處理的請求數。某個並發用戶數下單位時間內能處理的最大請求數，稱之為最大吞吐率。 記住：吞吐率是基於並發用戶數的。這句話代表了兩個含義： a、吞吐率和並發用戶數相關 b、不同的並發用戶數下，吞吐率一般是不同的 計算公式：總請求數/處理完成這些請求數所花費的時間，即 Request per second=Complete requests/Time taken for tests 。 必須要說明的是，這個數值表示當前機器的整體性能，值越大越好。 2、用戶平均請求等待時間（Time per request） 計算公式：處理完成所有請求數所花費的時間/（總請求數/並發用戶數），即： Time per request=Time taken for tests/（Complete requests/Concurrency Level） 。 3、服務器平均請求等待時間（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. 安裝：

[html] view plain copy

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

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

[html] view plain copy

1. [[email protected]]# make
2. cc -Wall -ggdb -W -O -c -o webbench.o webbench.c
3. webbench.c: In function ‘alarm_handler’:
4. webbench.c:77: warning: unused parameter ’signal’
5. cc -Wall -ggdb -W -O -o webbench webbench.o
6. ctags *.c
7. /bin/sh: ctags: command not found
8. make: [tags] Error 127 (ignored)

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

如果安裝了ctags, 仍然報錯:

[php] view plain copy

1. install -s webbench /usr/local/bin
2. install -m 644 webbench.1 /usr/local/man/man1
3. install: cannot create regular file `/usr/local/man/man1′: No such file or directory
4. 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

<?xmlversion="1.0"?> <!DOCTYPE tsung SYSTEM "/usr/share/tsung/tsung-1.0.dtd"> <tsungloglevel="notice"version="1.0"> <clients> <clienthost="localhost"weight="1"cpu="10"maxusers="40000"> <ipvalue="192.168.122.2"/> </client> <clienthost="loadnode1"weight="1"cpu="9"maxusers="40000"> <ipvalue="192.168.122.2"/> </client> <clienthost="loadnode2"weight="1"maxusers="40000"cpu="8"> <ipvalue="192.168.122.3"/> </client> <clienthost="loadnode3"weight="1"maxusers="40000"cpu="9"> <ipvalue="192.168.122.21"/> </client> <clienthost="loadnode4"weight="1"maxusers="40000"cpu="9"> <ipvalue="192.168.122.11"/> </client> <clienthost="loadnode5"weight="1"maxusers="40000"cpu="9"> <ipvalue="192.168.122.12"/> </client> <clienthost="loadnode6"weight="1"maxusers="40000"cpu="9"> <ipvalue="192.168.122.13"/> </client> <clienthost="loadnode7"weight="1"maxusers="40000"cpu="9"> <ipvalue="192.168.122.14"/> </client> </clients> <servers> <serverhost="192.168.122.10"port="80"type="tcp"/> </servers> <load> <arrivalphasephase="1"duration="10"unit="minute"> <usersmaxnumber="15000"arrivalrate="8"unit="second"/> </arrivalphase> <arrivalphasephase="2"duration="10"unit="minute"> <usersmaxnumber="15000"arrivalrate="8"unit="second"/> </arrivalphase> <arrivalphasephase="3"duration="30"unit="minute"> <usersmaxnumber="20000"arrivalrate="3"unit="second"/> </arrivalphase> </load> <sessions> <sessionprobability="100"name="ab"type="ts_http"> <forfrom="1"to="10000000"var="i"> <request> <httpurl="/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 aliastreport="/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 進行壓力測試。

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