效能測試中TPS上不去的幾種原因淺析

TPS（Transaction Per Second）：每秒事務數，指伺服器在單位時間內（秒）可以處理的事務數量，一般以request/second為單位。

下面就說說壓測中為什麼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：效能瓶頸分析不能單從區域性分析，要綜合起來，多維度分析問題原因。上面列出的幾點，可能有描述不當或者遺漏的，僅供參考。。