性能測試流程（重點）

需求調研-設計場景-製造腳本-準備環境 -瞭解配置-提出優化建議

壓測咱們都應該知道哪些：

1.壓測場景，用戶行爲

2.壓測機服務配置：

   核數，可用內存，網絡帶寬（上傳和下載速率=網絡帶寬/8），內網壓測（沒有帶寬限制，就至關於與在一個屋子裏幹活沒有門的限制），外網壓測（有帶寬限制）

3.應用服務器，數據庫服務：

好比放了mq的服務器那他CPU就可能降低的慢，若是mq的服務器CPU太高或者緩存太高那就可能說明mq裏面放的東西太多了，減小一些沒必要要的應用，好比CPU太高，能夠考慮調整內核參數，服務器下載寬帶太小，能夠加大寬帶，從原來的20kb加到50kb。

重點：若是所放的特殊應用的那臺服務器掛掉，那麼進入這個這個應用的業務也會癱瘓，這已經不是負載的事情了，會致使功能缺失業務癱瘓，好比：訂單進入mq，可是mq對應的這臺服務器掛掉了，那麼訂單處理這個業務就算缺失了，因此必定要清楚是怎麼負載的，程序在什麼狀況下，什麼時間節點進入那臺服務器，提出服務器分發建議。

4.瞭解每一個應用：

　　每一個應用都作了什麼？，他們作事的特色是什麼？，他們作事所消耗那些資源？（如：比較消耗內存，那些比較消耗cpu，那些比較吃寬帶）

5.分析指標：

　　CPU，內存，等在拐點變化時，服務器都在幹什麼？

　　CPU使用率到達多少時是最佳狀態/最糟糕的狀態，緩存，IO等達到多少時是最佳狀態/最糟糕狀態

　　聚合報告中：吞吐量（TPS），以及一些響應時間，理解個個指標之間的關係。

6.優化建議：

CPU太高：調整內核參數

內存太高：加大內存，調整任務分發比例，調小

Received KB/sec：  達到帶寬極限，加寬網絡寬帶，提升：上傳和下載速率=網絡寬帶/8

服務部署應用結構：好比放了mq的服務器那他CPU就可能降低的慢，若是mq的服務器CPU太高或者緩存太高那就可能說明mq裏面放的東西太多了，減小一些沒必要要的應用

　　重點：若是所放的特殊應用的那臺服務器掛掉，那麼進入這個這個應用的業務也會癱瘓，這已經不是負載的事情了，會致使功能缺失業務癱瘓，好比：訂單進入mq，可是mq對應的這臺服務器掛掉了，那麼訂單處理這個業務就算缺失了，因此必定要清楚是怎麼負載的，程序在什麼狀況下，什麼時間節點進入那臺服務器，提出服務器分發建議。

慢sql查詢：優化sql，優化數據庫。

代碼冗餘：優化程序。

7.其實咱們還能夠針對這上面的每一種指標均可以設計一種場景來看他們的瓶頸在哪裏

 

1、TPS：Transactions Per Second（每秒傳輸的事物處理個數），即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。（業務TPS = CAPS × 每一個呼叫平均TPS）

TPS是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求而後服務器作出反應的過程。客戶機在發送請求時開始計時，收到服務器響應後結束計時，以此來計算使用的時間和完成的事務個數。

通常的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統總體處理能力取決於處理能力最低模塊的TPS值。

 

2、QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準，在因特網上，做爲域名系統服務器的機器的性能常常用每秒查詢率來衡量。

對應fetches/sec，即每秒的響應請求數，也便是最大吞吐能力。

下面就說說壓測中爲何TPS上不去的緣由：

一、網絡帶寬

在壓力測試中，有時候要模擬大量的用戶請求，若是單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，那麼就會形成網絡資源競爭，間接致使服務端接收到的請求數達不到服務端的處理能力上限。

二、鏈接池

可用的鏈接數太少，形成請求等待。鏈接池通常分爲服務器鏈接池（好比Tomcat）和數據庫鏈接池（或者理解爲最大容許鏈接數也行）。

（關於鏈接池的具體內容，可參考以前的博客：性能測試：鏈接池和線程）

三、垃圾回收機制

從常見的應用服務器來講，好比Tomcat，由於java的的堆棧內存是動態分配，具體的回收機制是基於算法，若是新生代的Eden和Survivor區頻繁的進行Minor GC，老年代的full GC也回收較頻繁，那麼對TPS

也是有必定影響的，由於垃圾回收其自己就會佔用必定的資源。

四、數據庫配置

高併發狀況下，若是請求數據須要寫入數據庫，且須要寫入多個表的時候，若是數據庫的最大鏈接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等，

就會致使數據庫事務處理過慢，影響到TPS。

五、通訊鏈接機制

串行、並行、長鏈接、管道鏈接等，不一樣的鏈接狀況，也間接的會對TPS形成影響。

（關於協議的鏈接，可參考以前的博客：HTTP協議進階：鏈接管理）

六、硬件資源

包括CPU（配置、使用率等）、內存（佔用率等）、磁盤（I/O、頁交換等）。

七、壓力機

好比jmeter，單機負載能力有限，若是須要模擬的用戶請求數超過其負載極限，也會間接影響TPS（這個時候就須要進行分佈式壓測來解決其單機負載的問題）。

八、壓測腳本

仍是以jemter舉個例子，以前工做中同事遇到的，進行階梯式加壓測試，最大的模擬請求數超過了設置的線程數，致使線程不足。

提到這個緣由，想表達意思是：有時候測試腳本參數配置等緣由，也會影響測試結果。

九、業務邏輯

業務解耦度較低，較爲複雜，整個事務處理線被拉長致使的問題。

十、系統架構

好比是否有緩存服務，緩存服務器配置，緩存命中率、緩存穿透以及緩存過時等，都會影響到測試結果。

 

PS：性能瓶頸分析不能單從局部分析，要綜合起來，多維度分析問題緣由。上面列出的幾點，可能有描述不當或者遺漏的，僅供參考。。。

若是有不許確的，請評論指正，謝謝！