您好,登錄后才能下訂單哦!
本篇內容介紹了“性能測試中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、系統架構
比如是否有緩存服務,緩存服務器配置,緩存命中率、緩存穿透以及緩存過期等,都會影響到測試結果。
“性能測試中TPS上不去的原因有哪些”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。