需求調研-設計場景-制造腳本-准備環境 -了解配置-提出優化建議
壓測我們都應該知道哪些：
1.壓測場景，用戶行為
2.壓測機服務配置：
核數，可用內存，網絡帶寬（上傳和下載速率=網絡帶寬/8），內網壓測（沒有帶寬限制，就相當於與在一個屋子里干活沒有門的限制），外網壓測（有帶寬限制）
3.應用服務器，數據庫服務：
比如放了mq的服務器那他CPU就可能下降的慢，如果mq的服務器CPU過高或者緩存過高那就可能說明mq里面放的東西太多了，減少一些不必要的應用，比如CPU過高，可以考慮調整內核參數，服務器下載寬帶過小，可以加大寬帶，從原來的20kb加到50kb。
重點：如果所放的特殊應用的那台服務器掛掉，那么進入這個這個應用的業務也會癱瘓，這已經不是負載的事情了，會導致功能缺失業務癱瘓，比如：訂單進入mq，但是mq對應的這台服務器掛掉了，那么訂單處理這個業務就算缺失了，所以一定要清楚是怎么負載的，程序在什么情況下，什么時間節點進入那台服務器，提出服務器分發建議。
4.了解每個應用：
每個應用都做了什么？，他們做事的特點是什么？，他們做事所消耗那些資源？（如：比較消耗內存，那些比較消耗cpu，那些比較吃寬帶）
接口之間的調用鏈路關系：如mq消費鏈路圖，消費方式。
5.分析指標：
CPU，內存，等在拐點變化時，服務器都在干什么？
CPU使用率到達多少時是最佳狀態/最糟糕的狀態，緩存，IO等達到多少時是最佳狀態/最糟糕狀態
聚合報告中：吞吐量（TPS），以及一些響應時間，理解個個指標之間的關系。
6.優化建議：
CPU過高：調整內核參數
內存過高：加大內存，調整任務分發比例，調小
Received KB/sec： 達到帶寬極限，加寬網絡寬帶，提高：上傳和下載速率=網絡寬帶/8
服務部署應用結構：比如放了mq的服務器那他CPU就可能下降的慢，如果mq的服務器CPU過高或者緩存過高那就可能說明mq里面放的東西太多了，減少一些不必要的應用
重點：如果所放的特殊應用的那台服務器掛掉，那么進入這個這個應用的業務也會癱瘓，這已經不是負載的事情了，會導致功能缺失業務癱瘓，比如：訂單進入mq，但是mq對應的這台服務器掛掉了，那么訂單處理這個業務就算缺失了，所以一定要清楚是怎么負載的，程序在什么情況下，什么時間節點進入那台服務器，提出服務器分發建議。
慢sql查詢：優化sql，優化數據庫。
代碼冗余：優化程序。
7.其實我們還可以針對這上面的每一種指標都可以設計一種場景來看他們的瓶頸在哪里
一、TPS：Transactions Per Second（每秒傳輸的事物處理個數），即服務器每秒處理的事務數。TPS包括一條消息入和一條消息出，加上一次用戶數據庫訪問。（業務TPS = CAPS × 每個呼叫平均TPS）
TPS是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
一般的，評價系統性能均以每秒鍾完成的技術交易的數量來衡量。系統整體處理能力取決於處理能力最低模塊的TPS值。
二、QPS：每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准，在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。
對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。
下面就說說壓測中為什么TPS上不去的原因：
1、網絡帶寬
在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內傳遞的數據包過大，超過了帶寬的傳輸能力，那么就會造成網絡資源競爭，間接導致服務端接收到的請求數達不到服務端的處理能力上限。
2、連接池
可用的連接數太少，造成請求等待。連接池一般分為服務器連接池（比如Tomcat）和數據庫連接池（或者理解為最大允許連接數也行）。
（關於連接池的具體內容，可參考之前的博客：性能測試：連接池和線程）
3、垃圾回收機制
從常見的應用服務器來說，比如Tomcat，因為java的的堆棧內存是動態分配，具體的回收機制是基於算法，如果新生代的Eden和Survivor區頻繁的進行Minor GC，老年代的full GC也回收較頻繁，那么對TPS
也是有一定影響的，因為垃圾回收其本身就會占用一定的資源。
4、數據庫配置
高並發情況下，如果請求數據需要寫入數據庫，且需要寫入多個表的時候，如果數據庫的最大連接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等，
就會導致數據庫事務處理過慢，影響到TPS。
5、通信連接機制
串行、並行、長連接、管道連接等，不同的連接情況，也間接的會對TPS造成影響。
（關於協議的連接，可參考之前的博客：HTTP協議進階：連接管理）
6、硬件資源
包括CPU（配置、使用率等）、內存（占用率等）、磁盤（I/O、頁交換等）。
7、壓力機
比如jmeter，單機負載能力有限，如果需要模擬的用戶請求數超過其負載極限，也會間接影響TPS（這個時候就需要進行分布式壓測來解決其單機負載的問題）。
8、壓測腳本
還是以jemter舉個例子，之前工作中同事遇到的，進行階梯式加壓測試，最大的模擬請求數超過了設置的線程數，導致線程不足。
提到這個原因，想表達意思是：有時候測試腳本參數配置等原因，也會影響測試結果。
9、業務邏輯
業務解耦度較低，較為復雜，整個事務處理線被拉長導致的問題。
10、系統架構
比如是否有緩存服務，緩存服務器配置，緩存命中率、緩存穿透以及緩存過期等，都會影響到測試結果。
PS：性能瓶頸分析不能單從局部分析，要綜合起來，多維度分析問題原因。上面列出的幾點，可能有描述不當或者遺漏的，僅供參考。。。
如果有不准確的，請評論指正，謝謝！