性能测试：压榨一下 ServiceComb

开卷有益，关注我们

前言

本文以一个最简单的单consumer->单producer的测试场景为例，说明了如何在指定测试环境中，通过观察metrics统计数据，不断调整参数压榨出最大性能。

环境确认

01

使用华为云c3.2xlarge.2 VM

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

测试结果

汇总

关注我们

缘分，或许就在“好看”里

点 击“ 阅读原文 ”给 ServiceComb点个“Star”吧