壓測相關術語
響應時間(RT) ：指系統對請求作出響應的時間.
吞吐量(Throughput) ：指系統在單位時間內處理請求的數量
QPS每秒查詢率(Query Per Second) ：“每秒查詢率”，是一臺伺服器每秒能夠響應的查詢次數，是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
TPS(TransactionPerSecond)：每秒鐘系統能夠處理的交易或事務的數量
併發連線數：某個時刻伺服器所接受的請求總數 .

1、QPS（Queries Per Second）

概念：伺服器每秒處理查詢次數，是一臺伺服器每秒能夠處理的查詢次數。使用者發起查詢請求到伺服器做出響應這算一次，一秒內使用者完成了50次查詢請求，那此時伺服器QPS就是50。

2、TPS （Transactions Per Second）

概念：伺服器每秒處理的事務數，一個事物是使用者發起查詢請求到伺服器做出響應這算一次。納尼？這難道不是QPS的概念嗎？劃重點，這裡就要說清楚一個概念了，在針對單介面，TPS可以認為是等價於QPS的，如訪問 ‘order.html’ 這個頁面而言,是一個TPS。而訪問 ‘order.html’ 頁面可能請求了3此伺服器（如呼叫了css、js、order介面），這實際就算產生了三個QPS

所以，總結下就是，在針對單介面的時候TPS = QPS ,否則QPS就要看實際的請求次數了。

2、RT（Res（onse Time）

概念：響應實際，就是從客戶端請求發起到伺服器響應結果的時間。RT這個引數是系統最重要的指標之一，它的大小直接反應了當前系統的響應狀態。基本和咱們使用者體驗息息相關，現在好一點監控系統一般都有三個RT，即平均、最大、最小。

一般系統RT 100ms 以內是比較正常的，300ms 勉強可以接受，1s的話再加上一些其他的外因，給使用者的體驗就是實實在在的不爽了。

3、併發數

概念：系統能同時處理的請求的數量，很多人經常會把併發數和TPS理解混淆。舉例，請求一個index.html 頁面，客戶端發起了三個請求（css、js、index介面）,那麼此時TPS =1 、QPS =3 、併發數 3。

SO，計算公式 ： QPS=併發數/RT || 併發數=QPS*RT

4、吞吐量（Throughput）

概念：每秒承受的使用者訪問量，吞吐量（系統能承受多少壓力）和當前請求對CPU消耗、記憶體、IO使用等等緊密相關。單個請求消耗越高，系統吞吐量越低，反之越高。

一個系統的吞吐量和其TPS 、QPS、併發數息息相關，每個系統針對這些值都有一個相對極限值，只要其中某一個達到最大，系統的吞吐量也就到達極限了。如此時壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，各種資源切換等等的消耗導致系統性能下降。

關係：

所以，理解上面幾個關係後，就可以推算出：

QPS（TPS）= 併發數/平均響應時間

5、PV（Page View）

概念： 即每個頁面的瀏覽次數，使用者每次重新整理就算一次。

6、UV（Unique Visitor）

概念：獨立訪客數，每天訪問的使用者數，此資料需要根據使用者唯一標識進行去重。

7、Load（系統負載）

概念：此資料指的是Linux系統的負載情況，也就是咱們平時所用Top命令時，最上面顯示的資料資訊( load average: 0.1, 0.2, 0.5)。此時會顯示1分鐘、5分鐘、15分鐘的系統平均Load，很顯然load average 的值越低，你的系統負荷越小。

簡單的說下這個值應該怎麼看，如果你是單核cpu,那此值為1的時候就是系統已經滿負荷狀態了，需要你馬上去解決。但實際經驗告訴我們，當系統負荷持續大於0.7的時候（也就是70%），就需要你馬上來解決問題了，防止進一步惡化。

為什麼需要三個值 load average: 0.1, 0.2, 0.5，其實就是給你個參考。比如只有1分鐘的是1，其他倆都是0.1，這表明只是臨時突發的現象，問題不大。如果15分鐘內，系統負荷都是1或大於1，那表明問題持續存在啊。所以你應該主要觀察15分鐘的系統負荷。

apache有個自帶的ab工具

ab全稱Apache Bench，是Apache自帶的效能測試工具。使用這個工具，只須指定同時連線數、請求數以及URL，即可測試網站或網站程式的效能。

通過ab傳送請求模擬多個訪問者同時對某一URL地址進行訪問,可以得到每秒傳送位元組數、每秒處理請求數、每請求處理時間等統計資料。

命令格式：

ab [options] [http://]hostname[:port]/path

常用引數如下：

-n requests 總請求數
-c concurrency 一次產生的請求數，可以理解為併發數
-t timelimit 測試所進行的最大秒數, 可以當做請求的超時時間
-p postfile 包含了需要POST的資料的檔案
-T content-type POST資料所使用的Content-type頭資訊

更多引數請檢視官方文件。

例如測試某個GET請求介面：

ab -n 10000 -c 100 -t 10 "http://127.0.0.1:8080/api/v1/posts?size=10"

測試POST請求介面：

ab -n 10000 -c 100 -t 10 -p post.json -T "application/json" "http://127.0.0.1:8080/api/v1/post"

Apache JMeter是100%純JAVA桌面應用程式，被設計為用於測試客戶端/服務端結構的軟體(例如web應用程式)。它可以用來測試靜態和動態資源的效能，例如：靜態檔案，Java Servlet,CGI Scripts,Java Object,資料庫和FTP伺服器等等。JMeter可用於模擬大量負載來測試一臺伺服器，網路或者物件的健壯性或者分析不同負載下的整體效能。

同時，JMeter可以幫助你對你的應用程式進行迴歸測試。通過你建立的測試指令碼和assertions來驗證你的程式返回了所期待的值。為了更高的適應性，JMeter允許你使用正則表示式來建立這些assertions.

JMeter的作用對軟體做壓力測試

1.能夠對HTTP和FTP伺服器進行壓力和效能測試， 也可以對任何資料庫進行同樣的測試（通過JDBC）。

2.完全的可移植性和100% 純java。

3.完全 Swing 和輕量元件支援（預編譯的JAR使用 javax.swing.*)包。

4.完全多執行緒，框架允許通過多個執行緒併發取樣和通過單獨的執行緒組對不同的功能同時取樣。

5.精心的GUI設計允許快速操作和更精確的計時。

6.快取和離線分析/回放測試結果。

JMeter的高可擴充套件性

1.可連結的取樣器允許無限制的測試能力。

2.各種負載統計表和可連結的計時器可供選擇。

3.資料分析和視覺化外掛提供了很好的可擴充套件性以及個性化。

4.具有提供動態輸入到測試的功能（包括Javascript）。

5.支援指令碼程式設計的取樣器（在1.9.2及以上版本支援BeanShell）。

在設計階段，JMeter能夠充當HTTP PROXY（代理）來記錄IE/NETSCAPE的HTTP請求，也可以記錄apache等WebServer的log檔案來重現HTTP流量。當這些HTTP客戶端請求被記錄以後，測試執行時可以方便的設定重複次數和併發度（執行緒數）來產生巨大的流量。JMeter還提供視覺化元件以及報表工具把量伺服器在不同壓力下的效能展現出來。

相比其他HTTP測試工具,JMeter最主要的特點在於擴充套件性強。JMeter能夠自動掃描其lib/ext子目錄下.jar檔案中的外掛，並且將其裝載到記憶體，讓使用者通過不同的選單呼叫。

官方網站：http://jmeter.apache.org/

解壓後， 執行  “bin/jmeter.bat”   

Jmeter 是支援中文的， 啟動Jmeter 後， 點選 Options -> Choose Language  來選擇語言