古詩詞大全網 - 團隊口號 - JMeter測試配置優化指南

JMeter測試配置優化指南

經常有客戶問XMeter君,就是單個JMeter能最大支持多少虛擬用戶?這個問題其實很難給出壹個很準確的答案。因為虛擬用戶本身是壹個抽象的概念,每個虛擬用戶可以是模擬不同的協議。就像如果別人問某個容器能裝多少東西這種問題,因為東西本身不確定的話,妳也無法給出壹個確定的答案。當然了,容器大小本身是確定的,我們只能說在給定的容器的範圍內,是否有壹些方式來優化,能夠讓壹個容器裝下更多的壹個確定的東西。畢竟有的時候如果把所有潛能發揮出來,還是很可觀的呢。那言歸正傳,XMeter君帶大家來看看JMeter有哪些地方可以優化。

限制JMeter上模擬的虛擬用戶的瓶頸主要有計算資源(CPU),存儲(內存)和操作系統資源的限制等,下面分開講述。

計算資源主要指的就是CPU,不同的測試腳本對CPU的使用可能會有很大的差別。在編寫、執行測試腳本的時候可以考慮下面的壹些問題。

1)JMeter腳本在運行過程中應該避免循環執行大量計算的工作:比如測試腳本中每個虛擬用戶循環使用了BeanShell對數據進行處理,如果真的有此需求的話,建議使用擴展function。讀者可以參考XMeter君寫的 這篇文章 來比較BeanShell和原生function的處理效率。或者準備數據的部分是不是只需要執行壹次?比如將這部分邏輯放在“只執行壹次”控制器裏。

2)JMeter在UI模式下運行也會消耗更多的CPU資源,建議腳本調試通過之後,實際運行測試的時候通過在命令行下來運行測試腳本

3)JMeter的各種圖形化的監聽器也會消耗CPU資源,在實際的測試運行過程中可以把這些不必要的監聽器都關閉,只保留必要的監聽器

在自己實現插件的時候,需要考慮實現比較高效的壹些算法,如果壹個比較差的算法導致耗費額外的CPU,上千個線程累計起來是非常可觀的,所以在插件實現壹些偏計算的方面模擬的時候,壹定要做到精打細算。

存儲主要指的就是內存。JMeter是由Java實現的,而Java應用吃內存大家都覺得是很正常,但是這部分是否有優化的空間呢?答案是肯定的。JMeter和普通的Java應用程序壹樣,啟動後使用的內存主要包括兩個部分棧和堆。

1)棧空間主要用於分配在方法調用過程中壓入棧的方法調用的參數值等。棧空間的使用是和線程數目基本上成正比的,Java 8中缺省每個線程會分配1MB的棧空間。如果使用的是32位的系統,由於壹個進程的尋址空間為4GB,假設系統還需要留1GB的內存空間,那麽就算把所有的內存都分配給棧,最多也就是能創建3000個線程。當然,如果是使用了64位的系統的話,基本上就沒有這個限制了(實際上還受限於操作系統的壹些軟配置,本文稍後會提及)。假如妳的測試腳本(實際上取決於插件的實現)並沒有遞歸等復雜的棧調用,那麽可以把每個線程所需的棧空間調小。調每線程棧空間的使用可以通過打開jmeter.sh/jmeter.bat,通過加入下面的語句來解決,例子中的配置的意思是每線程使用400KB的棧空間,比缺省的1MB節省了約60%,對於需要創建大量的線程的JMeter來說,節省的空間還是比較可觀的。但是實際上在運行過程中,棧空間的使用也不完全是線性的,JVM或者操作系統可能在某些地方還是***享了壹些棧空間,具體的節省下來的棧空間需要通過試驗才能得到準確的數值。

2)堆則包括分配對象實例所需要的靜態變量、類變量等。這部分所用的內存取決於插件的實現,比如每個Sampler所依賴的對象的大小等。這部分空間的調整可以通過設置Xmx參數來實現。做法還是通過打開jmeter.sh/jmeter.bat,下面的例子的意思是上來就在堆空間上分配15GB內存,最大可以使用的堆的空間的大小也是15GB。

在自己實現JMeter插件的時候應該仔細考慮以上的問題,比如避免在Sampler中再單獨啟動線程,因為這麽做會使每個虛擬用戶創建額外的壹個線程,從而可能導致在同樣的配置下,妳實現的插件創建少壹半的虛擬用戶!比較好的做法是所有虛擬用戶通過壹個線程來處理,不過這樣也會導致多線程之間數據使用的沖突等問題,讀者需要根據自己的情況酌情處理。針對堆空間的使用,如果有比較占存儲空間的類變量,可能盡量多線程***享壹份數據(比如通過靜態變量等),而不是每線程創建自己的實例,當然還是需要考慮多線程訪問的時候變量保護的問題。

操作系統的缺省配置可以滿足大部分用戶的日常使用,而性能測試往往會突破這些操作系統默認的配置。常見的包括文件、端口限制等。本文以CentOS為例,介紹如何優化這些配置。

1)設定每個進程可以打開的最大文件描述符的數量,由於在Linux中壹個socket連接也是文件描述符,而性能測試過程過程中往往測試的時候也需要生成壹個socket連接,因此該參數的設置會影響到最大模擬的虛擬用戶數。

2)設置系統可用的socket端口號,每臺機器最多可用的端口號為65535,在測試機器上可能某些系統的端口已經被占用,因此用戶可以設置可用的端口號段來增加可用的端口。如下例所示可用的端口號為15000至61000,那麽最多的可用端口號數目為46000個。如果需要設置Docker容器中的該配置,需要在特權模式下才能對其進行配置,否則該項配置是只讀的(docker run --privileged)

3)tcp_tw_reuse表示可以復用處於TIME_WAIT狀態的連接,對於在性能測試過程中可能產生的大量臨時的短連接,該選項可以重用連接,而不用等待連接的完全釋放,從而能提高支持的並發用戶數目。tcp_tw_recycle用於回收處於TIME_WAIT狀態的連接,也可以提高連接的使用率。

4)提高線程的使用限制。pid_max用於控制操作系統線程ID的最大值,該值會影響可以創建的最大的線程數目。max_map_count單進程mmap的限制會影響當個進程可創建的線程數,需要將該值也提高以支持創建更多的線程。

通過上文的介紹,讀者可以對JMeter運行環境做壹些比較常見的優化。針對不同的測試,讀者還是需要分析不同的場景,針對壓力發起機的實際情況分別進行優化,以提高單臺機器上模擬的並發用戶數目。如果使用XMeter平臺,我們對壓力機已經進行了配置優化,避免測試人員糾結於類似的底層系統的配置,只需將精力放在測試業務邏輯的編寫和調試,執行的事情交給XMeter平臺就可以了,因此能極大地提高測試的工作效率。

什麽限制了創建Java線程的數量 :本文中介紹了更改棧大小的配置對生成的線程個數的影響

Java棧大小的設置 :與上文類似,介紹如何設置Java的棧大小

Linux中能創建的最大線程個數 : 本回答介紹的在Linux中對創建線程個數影響的壹些配置