常用性能壓測工具實戰總結

一、壓測背景

以前：未出社會之前經常用AB工具來壓測自己的 nginx 歡迎頁面，看着伺服器的資源從20%到100%，發現原來一個開源的工具都可以把一台4C8G的虛拟機壓爆滿，然後就陷入沉思，低成本的壓測都可以造成一台虛拟機的資源滿負載，而且還是個靜态頁面，那如果發生在企業身上會如何？造成的損失遠遠高于壓測方，後果不敢想象。

現在：我承認以前太天真了，既然有壓測方，那肯定有防禦方，遇到惡意壓測他人網站的，直接通過各種全家桶拉黑、屏蔽掉就好了。那對于現在企業來說，各人覺得最大的價值就是探測資源性能、資源容量合理規劃、增強業務穩定SLA、減少事故發生，這個對于測試還是運維來說都是天大的好事，也是價值的展現。

未來：壓測的普适性，對企業帶來的價值不止探測資源性能、資源容量合理規劃，還有技術架構更新驗證、業務系統上線測試、業務峰值穩定性測試等等，通過壓測清楚資源的能力，降低盲目預估的風險，提高服務的可用性和穩定性。

1.是以為什麼要做壓測？

壓測的目的就是通過壓測(模拟真實使用者的行為)，測算出機器的性能(單台機器的QPS)，進而推算出系統在承受指定使用者數(100W)時，需要多少機器能支撐得住壓測是在上線前為了應對未來可能達到的使用者數量的一次預估(提前演練)，壓測以後通過優化程式的性能或準備充足的機器，來保證使用者的體驗。

二、壓測工具

1.工具說明

AB：ApacheBench 是 Apache伺服器自帶的一個web壓力測試工具，簡稱ab。ab又是一個指令行工具，對發起負載的本機要求很低，根據ab指令可以建立很多的并發通路線程，模拟多個通路者同時對某一URL位址進行通路，是以可以用來測試目标伺服器的負載壓力。總的來說ab工具小巧簡單、非常輕量化的壓測工具，上手學習較快，可以提供需要的基本性能名額，但是沒有圖形化結果，不能監控。

Jmeter：Apache JMeter是Apache組織開發的基于Java的壓力測試工具。用于對軟體做壓力測試，它最初被設計用于Web應用測試，但後來擴充到其他測試領域。JMeter能夠對應用程式做功能/回歸測試，通過建立帶有斷言的腳本來驗證你的程式傳回了你期望的結果。

LoadRunner：LR是HP推出的一種預測系統行為和性能的負載測試工具，通過以模拟上千萬使用者實施并發負載及實時性能監測的方式來确認和查找問題，分為Windows 版本和Unix 版本。LoadRunner能夠對整個企業架構進行測試。企業也能最大限度地縮短測試時間，優化性能和加速應用系統的釋出周期。也能預測系統行為并優化系統性能。商業版支援錄屏+腳本的方式。

阿裡雲PTS：PTS（Performance Testing Service）是面向所有技術背景人員的雲化測試工具。有别于傳統工具的繁複，PTS以網際網路化的互動，提供性能測試、API調試和監測等多種能力。自研和适配開源的功能都可以輕松模拟任意體量的使用者通路業務的場景，任務随時發起，免去繁瑣的搭建和維護成本。更是緊密結合監控、流控等兄弟産品提供一站式高可用能力，高效檢驗和管理業務性能。當然也可以模拟***對業務系統進行全面深入的安全測試，

2.常用工具對比

對比項\壓測工具	Apache Bench（ab）	JMeter	LoadRunner	PTS
學習成本	低	高
安裝部署成本
費用	無		有
多協定	否	是
圖形化展示
TPS模式
壓測鍊路、場景編排管理
場景錄制
生态環境強弱	弱			強
監控名額是否完備
流量地域定制

3.壓測标準

壓測類型	解釋說明
壓力測試(Stress Testing)	也稱之為強度測試，測試一個系統的最大抗壓能力，在強負載(大資料、高并發)的情況下，測試系統所能承受的最大壓力，預估系統的瓶頸
并發測試(Concurrency Testing)	通過模拟很多使用者同一時刻通路系統或對系統某一個功能進行操作，來測試系統的性能，從中發現問題(并發讀寫、線程控制、資源争搶)
耐久性測試(Configuration Testing)	通過對系統在大負荷的條件下長時間運作，測試系統、機器的長時間運作下的狀況,從中發現問題(記憶體洩漏、資料庫連接配接池不釋放、資源不回收)

系統性能名額

3.1 交易響應時間

響應時間指使用者從用戶端發起一個請求開始，到用戶端接收到從伺服器端傳回的響應結束，整個過程所耗費的時間。在性能檢測中一般以壓力發起端至被壓測伺服器傳回處理結果的時間為計量，機關一般為秒或毫秒。平均響應時間指系統穩定運作時間段内，同一交易的平均響應時間。一般而言，交易響應時間均指平均響應時間。 平均響應時間名額值應根據不同的交易分别設定，一般情況下，分為複雜交易響應時間、簡單交易響應時間、特殊交易響應時間。其中，特殊交易響應時間的設定必須明确該交易在響應時間方面的特殊性。

Response Time: 簡稱RT

不同行業不同業務可接受的響應時間是不同的，一般情況，對于線上實時交易：

網際網路企業：500毫秒以下，例如淘寶業務10毫秒左右。

金融企業：1秒以下為佳，部分複雜業務3秒以下。

保險企業：3秒以下為佳。

制造業：5秒以下為佳。

對于批量交易：

時間視窗：即整個壓測過程的時間，不同資料量則時間不一樣，例如雙11和99大促，資料量級不一樣則時間視窗不同。大資料量的情況下，2小時内可完成壓測。

3.2 系統處理能力

系統處理能力是指系統在利用系統硬體平台和軟體平台進行資訊處理的能力。 系統處理能力通過系統每秒鐘能夠處理的交易數量來評價，交易有兩種了解：一是業務人員角度的一筆業務過程；二是系統角度的一次交易申請和響應過程。前者稱為業務交易過程，後者稱為事務。兩種交易名額都可以評價應用系統的處理能力。一般的建議與系統交易日志保持一緻，以便于統計業務量或者交易量。系統處理能力名額是技術測試活動中重要名額。

一般情況下，用以下名額來度量：

HPS（Hits Per Second） ：每秒點選次數，機關是次/秒。

TPS（Transaction per Second）：系統每秒處理交易數，機關是筆/秒。

QPS（Query per Second）：系統每秒處理查詢次數，機關是次/秒。 對于網際網路業務中，如果某些業務有且僅有一個請求連接配接，那麼TPS=QPS=HPS，一般情況下用TPS來衡量整個業務流程，用QPS來衡量接口查詢次數，用HPS來表示對伺服器單擊請求。

标準

無論TPS、QPS、HPS，此名額是衡量系統處理能力非常重要的名額，越大越好，根據經驗，一般情況下：

金融行業：1000 TPS~50000 TPS，不包括網際網路化的活動。

保險行業：100 TPS~100000 TPS，不包括網際網路化的活動。

制造行業：10 TPS~5000 TPS。

網際網路電子商務：10000 TPS~1000000 TPS。

網際網路中型網站：1000 TPS~50000 TPS。

網際網路小型網站：500 TPS~10000 TPS。

3.3 并發使用者

并發使用者數指在同一時刻内，登入系統并進行業務操作的使用者數量。 并發使用者數對于長連接配接系統來說最大并發使用者數即是系統的并發接入能力。對于短連接配接系統而言最大并發使用者數并不等于系統的并發接入能力，而是與系統架構、系統處理能力等各種情況相關。例如系統吞吐能力很強，加上短連接配接一般都有連接配接複用，往往并發使用者數大于系統的并發接入連接配接數。是以對于大部分短連接配接類型的系統，吞吐量模式（RPS模式，Request Per Second）比較适合，也是阿裡的最佳實踐，PTS支援RPS模式的壓測，吞吐量的壓測建構和衡量一步到位。 在測試中，采用虛拟使用者來模拟現實中使用者進行業務操作。

Virtual User：簡稱VU

一般情況下，性能測試是将系統處理能力容量測出來，而不是測試并發使用者數，除了伺服器長連接配接可能影響并發使用者數外，系統處理能力不受并發使用者數影響，可以用最小的使用者數将系統處理能力容量測試出來，也可以用更多的使用者将系統處理能力容量測試出來。

3.4 錯誤率

定義及解釋

錯誤率指系統在負載情況下，失敗交易的機率。錯誤率＝（失敗交易數/交易總數）×100%。穩定性較好的系統，其錯誤率應該由逾時引起，即為逾時率。

Virtual Failure Ratio：簡稱FR: VU

不同系統對錯誤率的要求不同，但一般不超出千分之六，即成功率不低于99.4%。

3.5 CPU

中央處理器是一塊超大規模的內建電路，是一台計算機的運算核心（Core）和控制核心（ Control Unit）。它的功能主要是解釋計算機指令以及處理計算機軟體中的資料。CPU Load：系統正在幹活的多少的度量，隊列長度。系統平均負載。

簡稱

Central Processing Unit：CPU

CPU名額主要指的CPU使用率、使用率，包括使用者态（user）、系統态（sys）、等待态（wait）、空閑态（idle）。CPU使用率、使用率要低于業界警戒值範圍之内，即小于或者等于75%、CPU sys%小于或者等于30%，CPU wait%小于或者等于5%。單核CPU也需遵循上述名額要求。CPU Load要小于CPU核數。

3.6 Memory

記憶體是計算機中重要的部件之一，它是與CPU進行溝通的橋梁。計算機中所有程式的運作都是在記憶體中進行的，是以記憶體的性能對計算機的影響非常大。

Memory就是記憶體的簡稱。

現代的作業系統為了最大利用記憶體，在記憶體中存放了緩存，是以記憶體使用率100%并不代表記憶體有瓶頸，衡量系統内有瓶頸主要靠SWAP（與虛拟記憶體交換）交換空間使用率，一般情況下，SWAP交換空間使用率要低于70%，太多的交換将會引起系統性能低下。

3.7 磁盤吞吐量

磁盤吞吐量是指在無磁盤故障的情況下機關時間内通過磁盤的資料量。

Disk Throughput。

磁盤名額主要有每秒讀寫多少兆，磁盤繁忙率，磁盤隊列數，平均服務時間，平均等待時間，空間使用率。其中磁盤繁忙率是直接反映磁盤是否有瓶頸的重要依據，一般情況下，磁盤繁忙率要低于70%。

3.8 網絡吞吐量

網絡吞吐量是指在無網絡故障的情況下機關時間内通過的網絡的資料數量。機關為Byte/s。網絡吞吐量名額用于衡量系統對于網絡裝置或鍊路傳輸能力的需求。當網絡吞吐量名額接近網絡裝置或鍊路最大傳輸能力時，則需要考慮更新網絡裝置。

Network Throughput

網絡吞吐量名額主要有每秒有多少兆流量進出，一般情況下不能超過裝置或鍊路最大傳輸能力的70%。

3.9 核心參數 作業系統核心參數主要包括信号量、程序、檔案句柄，一般不要超過設定的參數值即可，具體如下：	一級名額	二級名額	機關	解釋
核心參數	Maxuprc	個	限制每個使用者的使用者程序的最大數量
Max_thread_proc		定義每個程序允許的最大線程數量
Filecache_max	位元組	最大可用于cache file I/O的實體記憶體
Ninode		記憶體中HFS檔案系統打開i節點的最大數量
Nkthread		限制允許同時運作的線程數量
Nproc		限制允許同時運作的程序數量
Nstrpty		基于STREAMS的僞終端 （pts） 的最大數量
Maxdsiz		任何使用者程序的資料段的最大大小（以位元組為機關）
maxdsiz_64bit
maxfiles_lim		每個程序的檔案描述符的最大數目硬限制
maxssiz_64bit		任何使用者程序的堆棧的最大大小
Maxtsiz		任一使用者程序的文本段的最大大小
nflocks		檔案鎖的最大數量
maxtsiz_64bit
msgmni		系統級System V IPC消息隊列 （ID) 所允許的最大數量
msgtql		系統中任意時間的最大System V IPC消息數
npty		BSD僞終端 （pty） 的最大數量
nstrtel		指定核心可支援傳入telnet會話的telnet裝置檔案的數量
nswapdev		可用于交換的裝置的最大數量
nswapfs		可用于交換的檔案系統的最大數量
semmni		System V IPC系統級信号量辨別符的數量
semmns		System V系統級信号量的數量
shmmax		System V共享記憶體段的最大大小
shmmni		系統中System V共享記憶體段辨別符的數量
shmseg		每個程序System V共享記憶體段的最大數量

中間件名額

1.定義及解釋 常用的中間件例如Tomcat、Weblogic等名額主要包括JVM、ThreadPool、JDBC，具體如下：
GC	GC頻率	每秒多少次	Java虛拟機垃圾部分回收頻率
Full		每小時多少次	Java虛拟機垃圾完全回收頻率
	GC平均時長	秒	用于垃圾完全回收的平均時長
	GC最大時長		用于垃圾完全回收的最大時長
堆使用率	百分比	%
ThreadPool	Active Thread Count		活動的線程數
Pending	User Request		處于排隊的使用者請求個數
JDBC	JDBC Active Connection		JDBC活動連接配接數

2.标準

• 目前正在運作的線程數不能超過設定的最大值。一般情況下系統性能較好的情況下，線程數最小值設定50和最大值設定200比較合适。
• 目前運作的JDBC連接配接數不能超過設定的最大值。一般情況下系統性能較好的情況下，JDBC最小值設定50和最大值設定200比較合适。
• GC頻率不能頻繁，特别是FULL GC更不能頻繁，一般情況下系統性能較好的情況下，JVM最小堆大小和最大堆大小分别設定1024 M比較合适。

資料庫名額

常用的資料庫例如ＭySQL名額主要包括SQL、吞吐量、緩存命中率、連接配接數等，具體如下：
SQL	耗時	微秒	執行SQL耗時
吞吐量	QPS		每秒查詢次數
TPS 個	每秒事務次數
命中率	Key Buffer命中率	百分之	索引緩沖區命中率
InnoDB Buffer命中率		InnoDB緩沖區命中率
Query Cache命中率		查詢緩存命中率
Table Cache命中率		表緩存命中率
Thread Cache命中率		線程緩存命中率
鎖	等待次數	次	鎖等待次數
等待時間		鎖等待時間

• SQL耗時越小越好，一般情況下微秒級别。
• 命中率越高越好，一般情況下不能低于95%。
• 鎖等待次數越低越好，等待時間越短越好。

前端名額

前端名額主要包括頁面展示和網絡所花的時間，具體如下：
頁面展示	首次顯示時間	毫秒	在浏覽器位址欄輸入URL按回車到使用者看到網頁的第一個視覺标志為止。
OnLoad事件時間		浏覽器觸發onLoad事件的時間，當原始文檔和所有引用的内容完全下載下傳後才會觸發這個事件。
完全載入的時間		所有onLoad JavaScript處理程式執行完畢，所有動态的或延遲加載的内容都通過這些處理程式觸發的時間。
頁面數量	頁面大小	KB	整個頁面大小。
請求數量		從網站下載下傳資源時所有網絡請求的總數，盡量少。
網絡	DNS時間		DNS查找時間。
連接配接時間		連接配接時間就是浏覽器與Web伺服器建立TCP/IP連接配接的時間。
伺服器時間		伺服器處理時間。
傳輸時間		内容傳輸所用時間。
		等待某個資源釋放的時間。

• 頁面要盡可能小及壓縮。
• 頁面展示和花費時間越短越好。

穩定性名額

最短穩定時間：系統按照最大容量的80%或标準壓力（系統的預期日常壓力）情況下運作，能夠穩定運作的最短時間。 一般來說，對于正常工作日（8小時）運作的系統，至少應該能保證系統穩定運作８小時以上。對于7×24運作的系統，至少應該能夠保證系統穩定運作24小時以上。 如果系統不能穩定的運作，上線後，随着業務量的增長和長時間運作，将會出現性能下降甚至崩潰的風險。

• TPS曲線穩定，沒有大幅度的波動。
• 各項資源名額沒有洩露或異常情況。

批量處理名額

指批量處理程式機關時間内處理的資料數量。一般用每秒處理的資料量來衡量。處理效率是估算批量處理時間視窗最重要的計算名額。 關于批量處理時間視窗，不同系統的批量處理時間視窗在起止時間上可以部分重疊。另外，同一系統内部，也可能存在多個批量處理過程同時進行，其時間視窗互相疊加。 長時間批量處理将會對聯機線上實時交易産生重大的性能影響。

• 在資料量很大的情況下，批處理時間視窗時間越短越好。
• 不能影響實時交易系統性能。

可擴充性名額

指應用軟體或作業系統以叢集方式部署，增加的硬體資源與增加的處理能力之間的關系。計算公式為：（增加性能/原始性能）/（增加資源/原始資源）×100%。 擴充能力應通過多輪測試獲得擴充名額的變化趨勢。 一般擴充能力非常好的應用系統，擴充名額應是線性或接近線性的，現在很多大規模的分布式系統的擴充能力非常好。

• 理想的擴充能力是資源增加幾倍，性能就提升幾倍。
• 擴充能力至少在70%以上。

可靠性名額

1.雙機熱備

對于将雙機熱備作為可靠性保障手段的系統，可衡量的名額如下：

• 節點切換是否成功及其消耗時間。
• 雙機切換是否有業務中斷。
• 節點回切是否成功及其耗時
• 雙機回切是否有業務中斷。
• 節點回切過程中的資料丢失量。在進行雙機切換的同時，使用壓力發生工具模拟實際業務發生情況，對應用保持一定的性能壓力，保證測試結果符合生産實際情況。

2.叢集

對于使用叢集方式的系統，主要通過以下方式考量其叢集可靠性：

• 叢集中某個節點出現故障時，系統是否有業務中斷情況出現。
• 在叢集中新增一個節點時，是否需要重新開機系統。
• 當故障節點恢複後，加入叢集，是否需要重新開機系統。
• 當故障節點恢複後，加入叢集，系統是否有業務中斷情況出現。
• 節點切換需要多長時間。在驗證叢集可靠性的同時，需根據具體情況使用壓力工具模拟實際業務發生相關情況，對應用保持一定的性能壓力，確定測試結果符合生産實際情況。

3.備份和恢複

本名額為了驗證系統的備份、恢複機制是否有效可靠，包括系統的備份和恢複、資料庫的備份和恢複、應用的備份和恢複，包括以下測試内容：

• 備份是否成功及其消耗時間。
• 備份是否使用腳本自動化完成。
• 恢複是否成功及其消耗時間。
• 恢複是否使用腳本自動化完成名額體系的運用原則。
• 名額項的采用和考察取決于對相應系統的測試目的和測試需求。被測系統不一樣，測試目的不一樣，測試需求也不一樣，考察的名額項也有很大差别。
• 部分系統涉及額外的前端使用者接入能力的，需要考察使用者接入并發能力名額。
• 對于批量處理過程的性能驗證，主要考慮批量處理效率并估算批量處理時間視窗。
• 如測試目标涉及到系統性能容量，測試需求中應根據相關名額項的定義，明确描述性能名額需求。
• 測試名額擷取後，需說明相關的前提條件（如在多少的業務量、系統資源情況等）。

三、壓測價值

1.壓測流程

2.實作價值

可以快速定位瓶頸點：硬體、規格的瓶頸，中間件上的性能瓶頸、應用程式的瓶頸、作業系統上的瓶頸、網絡裝置上的瓶頸。

可以快速探測資源的狀态：

比如CPU使用率高，看CPU消耗User、Sys、Wait哪種狀态。

比如優化記憶體，給作業系統設定大量的cache，通過檢視某個程序所占用的記憶體或者交換記憶體去分析問題。

比如磁盤IO，通過降低輸出日志，異步或換速度快的硬碟來降低繁忙率。

比如網絡IO，通過壓縮減少内容大小、在本地設定緩存以及分多次傳輸等操作提高網絡I/O性能。

比如核心參數，一般都有預設值，這些核心參數預設值對于一般系統沒問題，但是對于壓力測試來說，可能運作的參數将會超過核心參數，導緻系統出現問題，可以用sysctl來檢視及修改。

比如JVM主要分析GC/FULL GC是否頻繁，以及垃圾回收的時間，可以用jstat指令來檢視，對于每個代大小以及GC頻繁，通過jmap将記憶體轉儲，再借助工具HeapAnalyzer來分析哪地方占用的記憶體較高以及是否有記憶體洩漏可能。

比如線程不夠用，可以通過參數調整，增加線程；對于線程池中的線程設定比較大的情況，還是不夠用可能的原因是：某個線程被阻塞來不及釋放，可能在等鎖、方法耗時較長、資料庫等待時間很長等原因導緻，需要進一步分析才能定位。

比如JDBC連接配接池不夠用的情況下，可以通過參數進行調整增加；但是對于資料庫本身處理很慢的情況下，調整沒有多大的效果，需要檢視資料庫方面以及因代碼導緻連接配接未釋放的原因。

3.性能調優

3.1調優步驟

确定問題

• 應用程式代碼：在通常情況下，很多程式的性能問題都是寫出來的，是以對于發現瓶頸的子產品，應該首先檢查一下代碼。
• 資料庫配置：經常引起整個系統運作緩慢，一些諸如大型資料庫都是需要DBA進行正确的參數調整才能投産的。
• 作業系統配置：不合理就可能引起系統瓶頸。
• 硬體設定：硬碟速度、記憶體大小等都是容易引起瓶頸的原因，是以這些都是分析的重點。
• 網絡：網絡負載過重導緻網絡沖突和網絡延遲。

3.2分析問題

• 當确定了問題之後，我們要明确這個問題影響的是響應時間吞吐量，還是其他問題？
• 是多數使用者還是少數使用者遇到了問題？如果是少數使用者，這幾個使用者與其它使用者的操作有什麼不同？
• 系統資源監控的結果是否正常？CPU的使用是否到達極限？I/O情況如何？
• 問題是否集中在某一類子產品中？
• 是用戶端還是伺服器出現問題？ 系統硬體配置是否夠用？
• 實際負載是否超過了系統的負載能力？ 是否未對系統進行優化？

通過這些分析及一些與系統相關的問題，可以對系統瓶頸有更深入的了解，進而分析出真正的原因。

3.3确定調整目标和解決方案

高系統吞吐量，縮短響應時間，更好地支援并發。

3.4測試解決方案

對通過解決方案調優後的系統進行基準測試。（基準測試是指通過設計科學的測試方法、測試工具和測試系統，實作對一類測試對象的某項性能名額進行定量的和可對比的測試）。

3.5分析調優結果

系統調優是否達到或者超出了預定目标；系統是整體性能得到了改善，還是以系統某部分性能來解決其他問題；調優是否可以結束了。 最後，如果達到了預期目标，調優工作可以先告一段落。

4.調優注意事項

• 在應用系統的設計開發過程中，應始終把性能放在考慮的範圍内，将性能測試常态化，日常化的内網的性能測試+定期的真實環境的業務性能測試，PTS都可以支援。
• 确定清晰明确的性能目标是關鍵，進而将目标轉化為PTS中的壓測場景并設定好需要的目标量級，然後視情況選擇并發、TPS模式，自動遞增/手工調速的組合進行流量控制。
• 必須保證調優後的程式運作正确。
• 系統的性能更大程度上取決于良好的設計，調優技巧隻是一個輔助手段。
• 調優過程是疊代漸進的過程，每一次調優的結果都要回報到後續的代碼開發中去。
• 性能調優不能以犧牲代碼的可讀性和可維護性為代價。

四、最佳實踐

1.AB工具安裝測試

leoheng@Leoheng-MBA ~ % yum -y install httpd-tools
leoheng@Leoheng-MBA ~ % ab -help
-n  即requests，用于指定壓力測試總共的執行次數。
-c  即concurrency，用于指定的并發數。
-t  即timelimit，等待響應的最大時間(機關：秒)。
-b  即windowsize，TCP發送/接收的緩沖大小(機關：位元組)。
-p  即postfile，發送POST請求時需要上傳的檔案，此外還必須設定-T參數。
-u  即putfile，發送PUT請求時需要上傳的檔案，此外還必須設定-T參數。
-T  即content-type，用于設定Content-Type請求頭資訊，例如：application/x-www-form-urlencoded，預設值為text/plain。
-v  即verbosity，指定列印幫助資訊的備援級别。
-w  以HTML表格形式列印結果。
-i  使用HEAD請求代替GET請求。
-x  插入字元串作為table标簽的屬性。
-y  插入字元串作為tr标簽的屬性。
-z  插入字元串作為td标簽的屬性。
-C  添加cookie資訊，例如："Apache=1234"(可以重複該參數選項以添加多個)。
-H  添加任意的請求頭，例如："Accept-Encoding: gzip"，請求頭将會添加在現有的多個請求頭之後(可以重複該參數選項以添加多個)。
-A  添加一個基本的網絡認證資訊，使用者名和密碼之間用英文冒号隔開。
-P  添加一個基本的代理認證資訊，使用者名和密碼之間用英文冒号隔開。
-X  指定使用的和端口号，例如:"126.10.10.3:88"。
-V  列印版本号并退出。
-k  使用HTTP的KeepAlive特性。
-d  不顯示百分比。
-S  不顯示預估和警告資訊。
-g  輸出結果資訊到gnuplot格式的檔案中。
-e  輸出結果資訊到CSV格式的檔案中。
-r  指定接收到錯誤資訊時不退出程式。
leoheng@Leoheng-MBA ~ % ab -c 100 -n 10000  https://www.123.com/
Server Software:        nginx/1.10.2 (伺服器軟體名稱及版本資訊)
Server Hostname:        192.168.1.106(伺服器主機名)
Server Port:            80 (伺服器端口)
Document Path:          /index1.html. (供測試的URL路徑)
Document Length:        3721 bytes (供測試的URL傳回的文檔大小)
Concurrency Level:      1000 (并發數)
Time taken for tests:   2.327 seconds (壓力測試消耗的總時間)
Complete requests:      5000 (的總次數)
Failed requests:        688 (失敗的請求數)
Write errors:           0 (網絡連接配接寫入錯誤數)
Total transferred:      17402975 bytes (傳輸的總資料量)
HTML transferred:       16275725 bytes (HTML文檔的總資料量)
Requests per second:    2148.98 [#/sec] (mean) (平均每秒的請求數) 這個是非常重要的參數數值，伺服器的吞吐量 
Time per request:       465.338 [ms] (mean) (所有并發使用者(這裡是1000)都請求一次的平均時間)
Time  request:       0.247 [ms] (mean, across all concurrent requests) (單個使用者請求一次的平均時間)
Transfer rate:          7304.41 [Kbytes/sec] received 每秒擷取的資料長度 (傳輸速率，機關：KB/s)
...
Percentage of the requests served within a certain time (ms)
  50%    347  ## 50%的請求在347ms内傳回 
  66%    401  ## 60%的請求在401ms内傳回 
  75%    431
  80%    516
  90%    600
  95%    846
  98%   1571
  99%   1593
 100%   1619 (longest request)           

2.Jmeter工具安裝測試

官網：https://jmeter.apache.org

備注：先安裝jdk1.8

leoheng@Leoheng-MBA ~ % wget https://mirrors.tuna.tsinghua.edu.cn/apache//jmeter/source/apache-jmeter-5.1.1_src.tgz
leoheng@Leoheng-MBA ~ % tar -xf apache-jmeter-5.1.1_src.tgz
leoheng@Leoheng-MBA ~ % export JMETER_HOME=/usr/local/apache-jmeter-5.1.1/ 
leoheng@Leoheng-MBA ~ % export CLASSPATH=$JMETER_HOME/lib/ext/ApacheJMeter_core.jar:$JMETER_HOME/lib/jorphan.jar:$JMETER_HOME/lib/logkit-2.0.jar:$CLASSPATH
leoheng@Leoheng-MBA ~ % export PATH=$JMETER_HOME/bin:$PATH:$HOME/bin
leoheng@Leoheng-MBA ~ % source /etc/profile 
leoheng@Leoheng-MBA ~ % jmeter -v
leoheng@Leoheng-MBA ~ % jmeter -n -t test.jmx -l result.jtl -e -o /tmp/ResultReport            

-n: 非GUI模式執行JMeter

-t: 執行測試檔案所在的位

-l: 指定生成測試結果的儲存檔案，.jtl檔案格式

-e: 測試結束後，生成測試報告

-o: 指定測試報告的存放位置

/tmp/ResultReport :手動建立的 ResultReport 報告檔案夾的路徑

3.Loadruner工具安裝測試

準備：LoadRunner Generator11.0 for Linux.iso、centos7測試機
把iso上傳到伺服器上，然後mount -o loop   LoadRunner Generator11.0 for Linux.iso /mnt 挂載到/mnt下。
leoheng@Leoheng-MBA ~ % yum install -y csh  glibc.i686 zlib.i686 libstdc++.so.5 && yum provides libgcc_s.so.1 -y
leoheng@Leoheng-MBA ~ % useradd -g 0 -s /bin/csh lr_agent
lr_agent:x:1005:0::/home/lr_agent:/bin/csh
leoheng@Leoheng-MBA ~ % ./mnt/installer.sh
leoheng@Leoheng-MBA ~ % chown -R lr_agent:lr_agent /opt/HP
leoheng@Leoheng-MBA ~ % vim /home/lr_agent/.bash_profile
export PATH
export PRODUCT_DIR=/opt/HP/HP_LoadGenerator
export M_LROOT=$PRODUCT_DIR
export LD_LIBRARY_PATH=${M_LROOT}/bin
export PATH=${M_LROOT}/bin:$PATH
leoheng@Leoheng-MBA ~ % csh /etc/csh.cshrc
leoheng@Leoheng-MBA ~ % source /opt/HP/HP_LoadGenerator/env.csh
leoheng@Leoheng-MBA ~ % source /home/lr_agent/.bash_profile
leoheng@Leoheng-MBA ~ % source /etc/csh.cshrc           

4.PTS工具測試

4.1.阿裡雲PTS控制台--》快速壓測