效能測試常用指標

吞吐量

說明：吞吐量（Throughput）：指的是單位時間內處理的客戶端請求數量，直接體現軟體系統的效能承載能力。
      通常情況下，吞吐量用“請求數/秒”或者“頁面數/秒”來衡量。
提示：
    1. 從業務角度來看，吞吐量也可以用“業務數/小時”、“業務數/天”、“訪問人數/天”、“頁面訪問量/天”來衡量。
    2. 從網路角度來看，還可以用“位元組數/小時”、“位元組數/天”等來衡量網路的流量。

每秒吞吐量統計(從網路角度)：
    當伺服器接受了請求後，就會響應給各個瀏覽器頁面，這些頁面攜帶都有大小的，以KB為單位計數，
    平均每秒吞吐量，代表了伺服器每秒響應的資訊量的大小,故每秒請求數越多,每秒吞吐量也就越多。
    請求數和吞吐量是成正比的。
    (因為有請求就有響應，請求是根據伺服器響應頁面中的狀態碼為標誌來統計的,簡單說就是請求數越多,
    伺服器根據請求響應的狀態碼就越多,，因此資訊量就上來了,故吞吐量(kb/s)就增加,因此請求數和吞吐量成正比)
 

併發數

說明：併發（Concurrency）：它最簡單的描述就是指多個同時發生的業務操作。
      （例如，100個使用者同時單擊登入頁面的“登入”按鈕操作。）
提示：併發性測試描述的是多個客戶端同時向伺服器發出請求，考察伺服器端承受能力的一種效能測試方式。
（多個“同時”傳送的“業務”操作,操作業務是一致的,在控制併發時通過集合點來實現）
這裡提一下：
  Jmeter是對介面併發測試的。
  LoadRunner是對業務集合形成的事務做併發測試的。
這就是為什麼說LoadRunner用來做web效能測試，而不是做介面測試原因,因為LoadRunner可變編寫指令碼指定事務開始和結束。
 

響應時間

說明：響應時間指使用者從客戶端發起一個請求開始，到客戶端接收到從伺服器端返回結果整個過程所耗費的時間

QPS/TPS/併發量/系統吞吐量

我們在日常工作中經常會聽到QPS/TPS這些名詞，也會經常被別人問起說你的系統吞吐量有多大。
這個問題從業務上來講，可以理解為應用系統每秒鐘最大能接受的使用者訪問量。或者每秒鐘最大能處理的請求數；

QPS“每秒查詢率”: 
    每秒鐘處理完請求的次數；注意這裡是處理完。具體是指發出請求到伺服器處理完成功返回結果。
    可以理解在server中有個counter，每處理一個請求加1，1秒後counter=QPS。

TPS每秒處理事務數：
	每秒鐘處理完的事務次數，一般TPS是對整個系統來講的。
    一個應用系統1s能完成多少事務處理，一個事務在分散式處理中，可能會對應多個請求，對於衡量單個介面服務的處理能力，用QPS比較多。

併發量：系統能同時處理的請求數

RT：響應時間，處理一次請求所需要的平均處理時間

計算關係：
	QPS = 併發量 / 平均響應時間 （每秒鐘能處理完的請求次數）
	併發量 = QPS * 平均響應時間
 

一、QPS/TPS
    QPS：
        Queries Per Second意思：是“每秒查詢率”，是一臺伺服器每秒能夠響應的查詢次數，
        		        是對一個特定的查詢伺服器在規定時間內所處理流量多少的衡量標準。
            
    TPS：
        是TransactionsPerSecond的縮寫，也就是事務數/秒。它是軟體測試結果的測量單位。
        一個事務是指一個客戶機向伺服器傳送請求然後伺服器做出反應的過程。客戶機在傳送請求時開始計時，收到伺服器響應後結束計時，
        以此來計算使用的時間和完成的事務個數。

    Tps即每秒處理事務數，包括了   
        1）使用者請求伺服器
        2）伺服器自己的內部處理
        3）伺服器返回給使用者
        這三個過程，每秒能夠完成N個這三個過程，Tps也就是N(這裡不是3，看我的csdn收藏原版)；

    QPS與TPS區別：
        Qps基本類似於Tps，但是不同的是，對於一個頁面的一次訪問，形成一個Tps；
        但一次頁面請求，可能產生多次對伺服器的請求，伺服器對這些請求，就可計入“Qps”之中。
        例如：訪問一個頁面會請求伺服器3次，一次產生一個“T”，產生3個“Q”  （因為頁面中可能會有圖片等資源去請求伺服器）

二、系統吞吐量
    一個系統的吞度量（承壓能力）與request對CPU的消耗、外部介面、IO等等緊密關聯。
    單個reqeust 對CPU消耗越高，外部系統介面、IO影響速度越慢，系統吞吐能力越低，反之越高。

    系統吞吐量幾個重要引數：QPS（TPS）、併發數、響應時間（還挺難理解的，不過看了3遍後終於理解它們之間的關係了，嘿嘿）

            QPS（TPS）：每秒鐘request/事務 數量

            併發數： 系統同時處理的request/事務數

            響應時間：  一般取平均響應時間

理解了上面三個要素的意義之後，就能推算出它們之間的關係：
    QPS（TPS）= 併發數/平均響應時間    或者   併發數 = QPS*平均響應時間

點選數

說明：點選數是衡量Web伺服器處理能力的一個重要指標。它的統計是客戶端向Web伺服器發了多少次HTTP請求計算的。

提示：
    1. 點選數不是通常一般人認為的訪問一個頁面就是１次點選數，點選數是該頁面包含的元素
    	（訪問一個頁面並響應，那就是一個事務數了）
        （如：圖片、連結、框架等）向Web伺服器發出的請求數數量。
    2. 通常我們也用每秒點選次數（Hits per Second）指標來衡量Web伺服器的處理能力。
    點選數，檢視響應狀態碼，訪問一個頁面可能有多個點選數，用F12檢視伺服器端的響應狀態碼，就可知道這個頁面有多少個點選數。
    點選數的統計是在伺服器端完成的。
    
結論：和qps概念類似

LoadRunner中合併圖的關係

1. 平均事務響應時間與虛擬執行使用者
2. 平均事務響應時間與吞吐量
3. 每秒點選數與吞吐量
4. 每秒點選數與平均事務響應時間

1. 說明：平均事務響應時間與吞吐量結合，可以看出單個事務對吞吐量的影響

2. 分析：
    1. 從上圖中看出，登入事務響應時間忽然拉長，系統吞吐量直線下降，說明，系統並不是因為總吞吐量的問題
       導致登入響應延長，基本確定是登入資源或登入業務程式碼響應時間增長導致的問題；

    2. 具體是登入資源還是登入業務，需要結合頁面元件細分圖和每秒點選數來確定是那個問題；

1. 說明：正常情況下每秒點選率與吞吐量圖形基本是一致的
2. 分析
    1. 吞吐量不正常那麼說明，應用程式響應時間慢
    2. 點選量不正常那麼說明，網路存在問題，需要檢查網路相關報表
3. 提示：一般測試不同配置伺服器效能時，這兩張圖合併最好用；

每秒點選數增多，平均事務響應時間變慢，事務響應時間拉長。