性能測試中TPS上不去的幾種緣由淺析

昨晚在某個測試羣看到有人問了一個問題：壓力測試中TPS一直上不去，是什麼緣由？稍微整理了下思路，列舉性的簡略回答了他的問題。

這篇博客，就具體說說在實際壓力測試中，爲何有時候TPS上不去的緣由。若有遺漏或不對的，請評論區指出，不勝感激。。。

 

先來解釋下什麼叫TPS：

TPS（Transaction Per Second）：每秒事務數，指服務器在單位時間內（秒）能夠處理的事務數量，通常以request/second爲單位。

關於性能測試的其餘一些常見術語，可參考以前的博客：性能測試：常見術語淺析

 

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

一、網絡帶寬

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

二、鏈接池

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

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

三、垃圾回收機制

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

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

四、數據庫配置

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

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

五、通訊鏈接機制

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

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

六、硬件資源

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

七、壓力機

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

八、壓測腳本

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

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

九、業務邏輯

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

十、系統架構

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

 

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

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