【轉】性能測試，影響 TPS 的一些因素

首先咱們要先了解下TPS的具體含義：

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

下面就說說壓測中爲何TPS上不去的緣由，影響它的一些因素：

一、網絡帶寬

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

二、鏈接池

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

三、垃圾回收機制

從常見的應用服務器來講，好比Tomcat，由於java的的堆棧內存是動態分配，具體的回收機制是基於算法，若是新生代的Eden和Survivor區頻繁的進行Minor GC，老年代的full GC也回收較頻繁，那麼對TPS也是有必定影響的，由於垃圾回收其自己就會佔用必定的資源。

四、數據庫配置

高併發狀況下，若是請求數據須要寫入數據庫，且須要寫入多個表的時候，若是數據庫的最大鏈接數不夠，或者寫入數據的SQL沒有索引沒有綁定變量，抑或沒有主從分離、讀寫分離等，就會致使數據庫事務處理過慢，影響到TPS。

五、通訊鏈接機制

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

六、硬件資源

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

七、壓力機

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

八、壓測腳本

仍是以jemter舉個例子，以前工做中同事遇到的，進行階梯式加壓測試，最大的模擬請求數超過了設置的線程數，致使線程不足。
提到這個緣由，想表達意思是：有時候測試腳本參數配置等緣由，也會影響測試結果。

九、業務邏輯

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

十、系統架構

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

十一、併發數

下面就拿具體的例子來講明一下

我記得我之前測文件上傳的壓力的時候帶寬對tps的影響是很是大的，好比我傳個文件大小5m，而測試機與服務器之間帶寬才100m，這個時候即便併發數夠大，可是因爲帶寬的限制，傳送的數據就只有那麼大，因此吞吐量怎麼也上不去。你們也能夠用傳送數據比較大的接口作個測試，親自體驗下。

鏈接池的影響就很好理解了，記得以前測hdfs系統的時候，用的是mongodb，配置了鏈接池。好比咱們當時配置了100個鏈接池，那麼當個人併發達到必定數量的時候，因爲鏈接池已經達到最大值，其餘請求只能處於等待的狀態，那麼即便服務器還能處理更多的請求，也因爲沒有更多的請求給服務器處理，所以這個時候tps也是上不去了。

再舉一個就是併發數對tps的影響：
下面有幾張圖

 

 

分別是1個併發，2個併發，50個併發持續請求1min後tps的值，很直觀的能夠看到，若是在沒有達到服務器處理瓶頸的時候，tps都是隨着同時請求的數量上升而提升。因此有些時候咱們在尋找系統瓶頸的時候能夠經過併發數的提升，而tps不升反而將的時候來判斷系統的瓶頸在哪裏。