本文版權歸XMeter所有，歡迎轉載，轉載請注明出處。
經常有客戶問XMeter君，就是單個JMeter能最大支持多少虛擬用戶？這個問題其實很難給出一個很準確的答案。因為虛擬用戶本身是一個抽象的概念，每個虛擬用戶可以是模擬不同的協(xié)議。就像如果別人問某個容器能裝多少東西這種問題，因為東西本身不確定的話，你也無法給出一個確定的答案。當然了，容器大小本身是確定的，我們只能說在給定的容器的范圍內，是否有一些方式來優(yōu)化，能夠讓一個容器裝下更多的一個確定的東西。畢竟有的時候如果把所有潛能發(fā)揮出來，還是很可觀的呢。那言歸正傳，XMeter君帶大家來看看JMeter有哪些地方可以優(yōu)化。
限制JMeter上模擬的虛擬用戶的瓶頸主要有計算資源（CPU），存儲（內存）和操作系統(tǒng)資源的限制等，下面分開講述。
計算資源
計算資源主要指的就是CPU，不同的測試腳本對CPU的使用可能會有很大的差別。在編寫、執(zhí)行測試腳本的時候可以考慮下面的一些問題。
1）JMeter腳本在運行過程中應該避免循環(huán)執(zhí)行大量計算的工作：比如測試腳本中每個虛擬用戶循環(huán)使用了BeanShell對數據進行處理，如果真的有此需求的話，建議使用擴展function。讀者可以參考XMeter君寫的這篇文章來比較BeanShell和原生function的處理效率?；蛘邷蕚鋽祿牟糠质遣皇侵恍枰獔?zhí)行一次？比如將這部分邏輯放在“只執(zhí)行一次”控制器里。
2）JMeter在UI模式下運行也會消耗更多的CPU資源，建議腳本調試通過之后，實際運行測試的時候通過在命令行下來運行測試腳本
3）JMeter的各種圖形化的監(jiān)聽器也會消耗CPU資源，在實際的測試運行過程中可以把這些不必要的監(jiān)聽器都關閉，只保留必要的監(jiān)聽器
在自己實現插件的時候，需要考慮實現比較高效的一些算法，如果一個比較差的算法導致耗費額外的CPU，上千個線程累計起來是非常可觀的，所以在插件實現一些偏計算的方面模擬的時候，一定要做到精打細算。
存儲資源
存儲主要指的就是內存。JMeter是由Java實現的，而Java應用吃內存大家都覺得是很正常，但是這部分是否有優(yōu)化的空間呢？答案是肯定的。JMeter和普通的Java應用程序一樣，啟動后使用的內存主要包括兩個部分棧和堆。
1）?？臻g主要用于分配在方法調用過程中壓入棧的方法調用的參數值等。?？臻g的使用是和線程數目基本上成正比的，Java 8中缺省每個線程會分配1MB的棧空間。如果使用的是32位的系統(tǒng)，由于一個進程的尋址空間為4GB，假設系統(tǒng)還需要留1GB的內存空間，那么就算把所有的內存都分配給棧，最多也就是能創(chuàng)建3000個線程。當然，如果是使用了64位的系統(tǒng)的話，基本上就沒有這個限制了（實際上還受限于操作系統(tǒng)的一些軟配置，本文稍后會提及）。假如你的測試腳本（實際上取決于插件的實現）并沒有遞歸等復雜的棧調用，那么可以把每個線程所需的棧空間調小。調每線程棧空間的使用可以通過打開jmeter.sh/jmeter.bat，通過加入下面的語句來解決，例子中的配置的意思是每線程使用400KB的?？臻g，比缺省的1MB節(jié)省了約60%，對于需要創(chuàng)建大量的線程的JMeter來說，節(jié)省的空間還是比較可觀的。但是實際上在運行過程中，?？臻g的使用也不完全是線性的，JVM或者操作系統(tǒng)可能在某些地方還是共享了一些?？臻g，具體的節(jié)省下來的棧空間需要通過試驗才能得到準確的數值。
JVM_ARGS="-XX:ThreadStackSize=400k"
2）堆則包括分配對象實例所需要的靜態(tài)變量、類變量等。這部分所用的內存取決于插件的實現，比如每個Sampler所依賴的對象的大小等。這部分空間的調整可以通過設置Xmx參數來實現。做法還是通過打開jmeter.sh/jmeter.bat，下面的例子的意思是上來就在堆空間上分配15GB內存，最大可以使用的堆的空間的大小也是15GB。
JVM_ARGS="-Xms15G -Xmx15G"
在自己實現JMeter插件的時候應該仔細考慮以上的問題，比如避免在Sampler中再單獨啟動線程，因為這么做會使每個虛擬用戶創(chuàng)建額外的一個線程，從而可能導致在同樣的配置下，你實現的插件創(chuàng)建少一半的虛擬用戶！比較好的做法是所有虛擬用戶通過一個線程來處理，不過這樣也會導致多線程之間數據使用的沖突等問題，讀者需要根據自己的情況酌情處理。針對堆空間的使用，如果有比較占存儲空間的類變量，可能盡量多線程共享一份數據（比如通過靜態(tài)變量等），而不是每線程創(chuàng)建自己的實例，當然還是需要考慮多線程訪問的時候變量保護的問題。
操作系統(tǒng)的限制
操作系統(tǒng)的缺省配置可以滿足大部分用戶的日常使用，而性能測試往往會突破這些操作系統(tǒng)默認的配置。常見的包括文件、端口限制等。本文以CentOS為例，介紹如何優(yōu)化這些配置。
1）設定每個進程可以打開的最大文件描述符的數量，由于在Linux中一個socket連接也是文件描述符，而性能測試過程過程中往往測試的時候也需要生成一個socket連接，因此該參數的設置會影響到最大模擬的虛擬用戶數。
ulimit -n 65535
2）設置系統(tǒng)可用的socket端口號，每臺機器最多可用的端口號為65535，在測試機器上可能某些系統(tǒng)的端口已經被占用，因此用戶可以設置可用的端口號段來增加可用的端口。如下例所示可用的端口號為15000至61000，那么最多的可用端口號數目為46000個。如果需要設置Docker容器中的該配置，需要在特權模式下才能對其進行配置，否則該項配置是只讀的(docker run --privileged）
sysctl -w net.ipv4.ip_local_port_range="15000 61000"?
3）tcp_tw_reuse表示可以復用處于TIME_WAIT狀態(tài)的連接，對于在性能測試過程中可能產生的大量臨時的短連接，該選項可以重用連接，而不用等待連接的完全釋放，從而能提高支持的并發(fā)用戶數目。tcp_tw_recycle用于回收處于TIME_WAIT狀態(tài)的連接，也可以提高連接的使用率。
sysctl -w net.ipv4.tcp_tw_reuse=1?
sysctl -w net.ipv4.tcp_tw_recycle=1
4）提高線程的使用限制。pid_max用于控制操作系統(tǒng)線程ID的最大值，該值會影響可以創(chuàng)建的最大的線程數目。max_map_count單進程mmap的限制會影響當個進程可創(chuàng)建的線程數，需要將該值也提高以支持創(chuàng)建更多的線程。
echo 999999 > /proc/sys/kernel/pid_max
echo 1999999 > /proc/sys/vm/max_map_count
總結
通過上文的介紹，讀者可以對JMeter運行環(huán)境做一些比較常見的優(yōu)化。針對不同的測試，讀者還是需要分析不同的場景，針對壓力發(fā)起機的實際情況分別進行優(yōu)化，以提高單臺機器上模擬的并發(fā)用戶數目。如果使用XMeter平臺，我們對壓力機已經進行了配置優(yōu)化，避免測試人員糾結于類似的底層系統(tǒng)的配置，只需將精力放在測試業(yè)務邏輯的編寫和調試，執(zhí)行的事情交給XMeter平臺就可以了，因此能極大地提高測試的工作效率。
參考資料
什么限制了創(chuàng)建Java線程的數量：本文中介紹了更改棧大小的配置對生成的線程個數的影響
Java棧大小的設置：與上文類似，介紹如何設置Java的棧大小
Linux中能創(chuàng)建的最大線程個數： 本回答介紹的在Linux中對創(chuàng)建線程個數影響的一些配置
