效能測試：壓榨一下 ServiceComb

摘要： 開卷有益，關注我們 前言 本文以一個最簡單的單consumer->單producer的測試場景為例，說明了如何在指定測試環境中，通過觀察metrics統計資料，不斷調整引數壓榨出最大效能。 基本測試過程： 測試驅動加大壓力，TPS...

開卷有益，關注我們

前言

本文以一個最簡單的單consumer->單producer的測試場景為例，說明了如何在指定測試環境中，通過觀察metrics統計資料，不斷調整引數壓榨出最大效能。

環境確認

01

使用華為雲c3.2xlarge.2 VM

華為雲c3.2xlarge.2 VM
Node1	192.168.26.44
Node2	192.168.29.195
備註：Node1 ping Node2：平均0.171ms

02

網路

開啟網絡卡的RSS特性，執行ethtool -l eth0，得到類似下圖的資料。

如果Pre-set的Combined不等於Current的Combined，則執行ethtool -L eth0 combined {Pre-Set Combined}改為相等，在這裡應該是ethtool -L eth0 combined 4

開啟網路佇列的自動負載均衡：service irqbalance start

03

CPU

cat /proc/cpuinfo | grep name

8  Intel(R) Xeon(R) Gold 6151 CPU @ 3.00GHz

04

記憶體

dmidecode -t memory

16GB

部署

01

service center

1. 下載service center

   http://mirror.bit.edu.cn/apache/servicecomb/servicecomb-service-center/1.1.0/apache-servicecomb-service-center-1.1.0-linux-amd64.tar.gz

2. 上傳到Node2，解壓

3. 修改conf/app.conf，監聽地址設為Node2小網IP

   Httpaddr = 192.168.29.195

4. 啟動service center

02

編譯用例工程

1. 下載原始碼

   git clone https://github.com/apache/servicecomb-java-chassis.git

2. 編譯

   mvn clean install -Dmaven.test.skip=true

   cd demo/perf

   mvn install -Pdemo-run-release -Dmaven.test.skip=true

編譯時增加maven.test.skip僅僅是為了加快編譯速度。

03

Producer

1. 在Node2的demo/target/perf目錄中新建microservice.yaml：

   service_description:

   name: perf1

   servicecomb:

   service:

   registry:

   address: http://192.168.29.195:30100

   highway:

   address: 192.168.29.195:7070

   server:

   thread-count: 1

   rest:

   address: 192.168.29.195:8080

   server:

   thread-count: 1

   response-size: 1024

2. 啟動：

   java –jar perf*

04

測試驅動：Consumer

1. 在Node1的demo/target/perf目錄中新建microservice.yaml：

   service_description:

   name: consumer

   servicecomb:

   service:

   registry:

   address: http://192.168.29.195:30100

   highway:

   address: 192.168.26.44:7070

   client:

   thread-count: 1

   rest:

   address: 192.168.26.44:8080

   client:

   thread-count: 1

   connection:

   maxPoolSize: 5

   references:

        transport: highway

   metrics:

   window_time: 1000

   publisher.defaultLog:

   enabled: true

   endpoints.client.detail.enabled: true

2. 啟動：

   java –jar perf* -c

Highway

01

同步調優

02

Reactive調優

Consumer的microservice.yaml中配置：

async-count: 1

sync: false

TPS/時延/CPU/頻寬消耗都很低

1、此時驅動併發度才1，太低，加大驅動壓力到500。

2、1個併發驅動，有2條連線，是因為開始壓測前，獨立呼叫了一次，用於列印呼叫結果；從非eventloop執行緒發起reactive呼叫，會隨機選擇一個網路執行緒去建立連線。

async-count: 500

Consumer最大時延偏高，Producer CPU消耗偏低

1、該環境中RSS網路佇列只有4個，與CPU數不對等，限制了併發能力，所以Producer CPU偏低。

2、在reactive場景下，網路執行緒即業務執行緒，有任何的波動，都會導致最大時延變大。

RESTful

ServiceComb中不同transport切換，只需要修改配置，無需修改業務程式碼。

Consumer的microservice.yaml中配置：

Servicecomb:

references:

   transport: rest

sync-count: 500

sync: true

01

同步調優

02

Reactive調優

直接調大連線池

servicecomb:

rest:

client:

connection:

maxPoolSize: 30

async-count: 500

sync: false

CPU基本耗盡，時延偏大，考慮降低驅動壓力到100。

servicecomb:

rest:

client:

connection:

maxPoolSize: 15

async-count: 100

測試結果

彙總

關注我們

緣分，或許就在“好看”裡