先來解釋下什麽叫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：性能瓶頸分析不能單從局部分析，要綜合起來，多維度分析問題原因。上面列出的幾點，可能有描述不當或者遺漏的，僅供參考。。。

如果有不準確的，請評論指正，謝謝！

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