壓測思路：

壓測consumer的Controller，呼叫provider暴露的介面。

provider做1w次迴圈，生成隨機數做累加。

provider再把consumer的入參無處理返回給consumer。

1、準備

使用的工具：

1、gc視覺化工具：https://gceasy.io

2、壓測工具：jmeter5.1（其他版本不相容dubbo）

3、jmeter 外掛，在jmeter官網可以找到，主要用來獲取響應時間、TPS 引數

4、ServerAgent外掛，jmeter的官方監測工具，用於收集伺服器的CPU、磁碟、頻寬、記憶體 引數。

5、jmeter整合dubbo外掛，可以直接使用dubbo://

序列化：

dubbo協議預設為hessian2，rmi協議預設為java，http協議預設為json

使用 jmeter 官方自帶的 servergent 收集伺服器資訊：

[root@GZSB-CJB-SHH10-8-LASTMILE-32 ServerAgent-2.2.3]# ./startAgent.sh 
INFO    2021-11-25 14:06:18.483 [kg.apc.p] (): Binding UDP to 4444
INFO    2021-11-25 14:06:19.490 [kg.apc.p] (): Binding TCP to 4444
INFO    2021-11-25 14:06:19.497 [kg.apc.p] (): JP@GC Agent v2.2.3 started
 

consumer程式碼：

   @DubboReference(version = "*", protocol = "dubbo,hessian", loadbalance = "random",retries = 0)
   private StressTestService stressTestService;
    
   @RequestMapping("/stressTest/string1k")
    public Boolean string1k(){
        // IO操作讀取1k資料
        String s = new FileCapacity().getFileCapacity(1*1024);
        String result = stressTestService.StressString1k(s);
        log.info("stressTest/string1k:{},num:{}",result.length(),a);
        return true;
    }
 

2、Jmeter壓測情況

環境：

provider:

jdk：1.8

2h4g

CentOS release 6.4 (Final)
model name      : QEMU Virtual CPU version 2.5+
stepping        : 3
cpu MHz         : 2099.998
cache size      : 4096 KB

宿主機頻寬 ：

1G 

jvm引數：

-server -Xmx2g -Xms2g -Xmn256m -Xss256k -XX:+UseG1GC 
-Xloggc:/data/dubboStress/logs/dubbo_gc_thrift.log -XX:+PrintGC -XX
:+PrintGCDetails

jmeter引數：

20個併發執行緒1s內發出，持續 10分鐘

需要提前設定一些收集的引數：

cpu、記憶體、磁碟IO、networkIO需通過 servergent 進行收集。

本次試驗是不以壓滿provider為目標，只是單純測試 10分鐘的情況。

均採取 dubbo2.7.13+hessian2 ，壓測10分鐘，20併發，結果如下：

windows執行可能會遇到 Adress bind already use ，因為windows的埠回收比較慢，樣本大的時候無法及時提供埠，因為jmeter每一個執行緒都需要開啟一個socket埠和consumer通訊，需要自行修改登錄檔修改。

可以看到 100k 資料的時候，dubbo的響應時間很慢、tps也低。

consumer ping provider 延遲差不多是7ms

同機房延遲是 0.2ms

provider 在 1k 和 100k 的top：

• 1k

Tasks: 118 total,   1 running, 117 sleeping,   0 stopped,   0 zombie
Cpu0  : 23.6%us, 16.7%sy,  0.0%ni, 57.6%id,  0.3%wa,  0.0%hi,  1.7%si,  0.0%st
Cpu1  :  5.0%us,  7.7%sy,  0.0%ni, 87.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3924680k total,  3201900k used,   722780k free,   318184k buffers
Swap:  2097144k total,       64k used,  2097080k free,  1186712k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
19560 root      20   0 3834m 826m  13m S 33.3 21.6   0:43.04 java    

• 100k

top - 09:49:23 up 528 days, 17:07,  4 users,  load average: 0.16, 0.29, 0.21
Tasks:   1 total,   0 running,   1 sleeping,   0 stopped,   0 zombie
Cpu0  : 16.1%us,  2.1%sy,  0.0%ni, 80.7%id,  0.0%wa,  0.0%hi,  1.1%si,  0.0%st
Cpu1  :  8.1%us,  1.3%sy,  0.0%ni, 90.6%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   3924680k total,  2971000k used,   953680k free,   320012k buffers
Swap:  2097144k total,       64k used,  2097080k free,  1185236k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                       
29635 root      20   0 4713m 632m  12m S 26.0 16.5   3:49.77 java

3、總結

以上僅僅對consumer呼叫，而再發起對provider的呼叫，而非直接使用dubbo協議直接呼叫provider。測試了一下，兩者區別較大，畢竟前者多了一層consumer，如圖：

（上述用的是思路一，思路二需要自行安裝dubbo外掛）

但思路一和使用 ab 測試結果差別不大，而且jmeter還可以生成很多圖表，各位可以嘗試一下。

參考：

• 服務端的cpu、記憶體監測，下載：https://www.cnblogs.com/imyalost/p/7751981.html
• jmeter版本和serverAgent版本問題：https://www.cnblogs.com/SunshineKimi/p/11361216.html