分布式压测

如何开展分布式压测？

当接到一个压测需求时，要怎么测试？一般可从以下角度阐述：

1、分析被测服务的调用链及其协议，选择测试工具

2、编写测试用例，准备测试数据，确认本地调试通过

3、准备发压环境

4、确认测试指标，选择测试场景

5、测试执行

6、总结和分析

一、测试工具

1.1 Jmeter

Jmeter常用于Web场景的压力测试。但除了常见的HTTP、TCP协议的性能测试外，Jmeter本身也提供了底层SDK以供开发者进行可视化的自定义开发。

TarsJmeter插件
    Tars是由腾讯开源的高性能RPC微服务框架。
    [TarsJMeter是一套运行在JMeter环境上的性能测试方案，目的是为了解决Tars私有化协议的性能测试。
    (下载地址：https://git.code.oa.com/dcsiq_sec_gz/tars_jmeter)
    
如何使用TarsJmeter插件？
    1、编译打包，生成TencentJMeter_tars-1.0.jar
    2、将 TencentJMeter_tars-1.0.jar 放到Jmeter的 .../lib/ext 目录下
    3、添加取样器时即可选择Tars or Shark相关Sampler

二、用例设计

2.1 常用测试协议

2.1.1 shark

Shark Sampler中，Shark协议总共有6种：

tcpShark nohttp：tcp on shark on tcp，长链接

tcpShark http：http on shark on tcp，长链接

OldtcpShark nohttp：tcp on old shark on tcp，长链接

OldtcpShark http：http on old shark on tcp，长链接

httpShark nohttp：tcp on shark on http，短链接

httpShark http：http on shark on http，短链接

其中，OldShark是指旧Mazu，旧的是链路只有Mazu，新的是Mazu+SashimiServer。目前TMF使用的是新Mazu，因此常用协议为tcpShark http。

2.1.2 tars

2.1.3 http

2.2 常用设置

2.2.1 线程组

线程数：通常从较小的数值开始测试，然后逐渐加大并发；

Ramp-Up时间：指多长时间内启动完全部线程，设置30即30s秒启动完全部线程。设置该参数可以模拟一段时间内都平稳有请求上去，避免请求全都在同一时间起来。

如何合理设置线程数？

通常情况下，QPS开始会随着压测端线程数而增加，到达极限值后不再上涨，因此测试的时候需要预估合理的线程数来达到极限QPS。

1、验证单个请求的响应时间（RT）

2、预估线程数 = RT x CPU核数 x 单CPU使用率 = RT x CPU核数 x 100%

2.2.2 定时器

定时器可以用于控制发送频率。（比如，想控制每秒发送一次，可以使用常数吞吐量定时器，设置为60）

常用的两种定时器：

固定定时器：一次请求后，延迟多长时间，再进行下一次请求

常数吞吐量定时器：指定每分钟最多发送多少个请求

何时需要用定时器？怎么设置参数？

在不设置定时器的情况下，会根据回包再发送下一个请求。因此定时器通常不是必须设置项。但在需要控制发包频率的场景时，可以设置。（例子：问题定位-网关HTTP协议）

先设置1个线程运行，观察响应时间（RT）。假设RT=1ms，即每分钟最多可发送请求数：60/1/0.001

2.2.3 查看结果树

添加查看结果树，可以看到每次请求的结果，也可只过滤失败请求。这个方便在本地调试使用。

2.2.4 后端监听器

后端监听器可以将测试结果传到influxdb，grafana从influxdb读取结果进行可视化展示，方便实时查看测试结果（QPS、错误率、耗时等）。

2.2.5 聚合报告

聚合报告可以显示错误率、TPS等结果信息，在没有可视化报表等情况下，可以用Jmeter自带的聚合报告看到测试结果。

2.2.6 CSV数据文件设置

适用于需要读取特定文件内容的场景。

三、环境管理

3.0 压测方式

压测可分为内网压测和外网压测。TMF是使用腾讯云服务器私有化部署，在办公网进行压测为外网压测；使用同一个腾讯云账号购买服务器进行压测，即为内网压测。

外网压测网络开销对响应耗时的影响较大，而内网压测几乎取消了网络开销的影响，可以更好地评估服务自身的性能，因此我们采用了内网压测。（客户端RT=服务端RT+网络开销）

3.1 环境依赖

确认是否安装了Java。若没有安装，则：

yum search jdk
yum install java-1.8.0-openjdk.x86_64

安装成功后，配置.bashrc：

export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export CLASSPATH=.:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
export PATH=${JAVA_HOME}/bin:$PATH

修改后，执行source ~/.bashrc生效

source ~/.bashrc

3.2 Jmeter部署

（1）分别登录5台压测机器，将jmeter打包上传上去，解压：

（2）修改.bashrc配置，配置jmeter的bin目录

export JMETER_HOME=/root/apache-jmeter-5.2.1
export PATH=${JMETER_HOME}/bin:${JAVA_HOME}/bin:$PATH

修改后，执行source ~/.bashrc生效

source ~/.bashrc

（3）设置jmeter分布式压测

修改 /apache-jmeter-5.2.1/bin/jmeter.properties，设置remote_hosts；

ip设置为压测机器，端口通常设置为1099

remote_hosts=ip1:port,ip2:port,ip3:port,ip4:port,ip5:port;

修改server.rmi.ssl.disable=true

server.rmi.ssl.disable=true

3.3 TarsJmeter插件替换

分别登录5台压测机器，上传插件：

TencentJMeter_tars-1.0.jar 到 /apache-jmeter-5.2.1/lib/ext

3.4 清理环境，启动Jmeter

分别登录5台压测机器，执行以下操作：

（1）清理环境：

ps aux | grep jmeter | xargs kill -9
rm -rf nohup.out
rm -rf jmeter-server.log
rm -rf taf/nohup.out

（2）每个机器执行对应ip的命令，启动jmeter：

nohup jmeter-server -Djava.rmi.server.hostname=本机ip -n &

3.5 常见问题

（1）执行用例时，出现Engine is busy…

解决方法：执行3.4进行环境清理

（2）启动Jmeter时提示无权限

解决方法：

sudo chmod -R 777 apache-jmeter-5.2.1

（3）运行用例时提示 Connection refused to host

解决方法：

修改master机器的 jmeter.bat：

set rmi_host=-Djava.rmi.server.hostname=本机ip

修改salve机器的 jmeter-server：

RMI_HOST_DEF=-Djava.rmi.server.hostname=本机ip

四、用例执行

4.1 测试前确认

（1）确认压测环境能否通过内网访问被测环境

telnet ip port

若不是同一账号下的腾讯云机器，内网ip不通，需要另外准备测试机。

（2）确认压测环境能否访问influxdb的ip

telnet ip port

如果不通，提供出口ip和被访ip，找运维开白名单：

curl cip.cc  # 查看出口ip
nslookup 域名  # 查看被访ip

4.2 执行用例

（1）上传用例

登录master机器，上传jmx文件放到 /taf 目录下

（2）/taf 目录下，执行：

nohup jmeter -n -t xxx.jmx -r &

若需要生成jmeter原生报告（.jtl），则使用以下命令：

nohup jmeter -n -t xxx.jmx -r -l report.jtl &

备注：nohup 是为了将进程放到后台运行，避免跳板机中断导致的各种问题。如，强制中断会导致无法停止运行，下次执行出现Engine is busy，此时需要清理环境（详见3.4）。

4.3 停止测试

登录master机器，根目录执行命令：

stoptest.sh
shutdown.sh

五、测试结果查看

5.1 查看当前执行情况

登录master机器，进入执行用例的目录，执行命令：

cat nohup.out

5.2 Jmeter原生报告

（1）执行用例时使用 -l 生成 .jtl 报告

nohup jmeter -n -t xxx.jmx -r -l report.jtl &

（2）.jtl 转 .html

jmeter -g report.jtl所在目录 -o 生成结果目录

5.3 grafana实时图表

后端监听器将测试结果传入influxdb，grafana再从influxdb读取数据进行展示。方便实时查看测试结果。

六、常用测试指标

6.1 QPS

QPS是后台服务压测最常见的指标。

影响QPS的可能因素有很多，从宏观归结来看，主要可以分为两个：耗时、CPU。不同因素的影响，通常都是对耗时和CPU产生影响。

如何测试QPS极限值？

预估最大值QPS = 1000ms / CPU Time x CPU核数 x CPU使用率

但实际测试过程中，由于种种原因，通常会遇到没有压到预期最大QPS的情况。比如，CPU使用率没有压满，但QPS不再上涨。如何判断此时的QPS是否已经达到极限值？

根据实践经验总结，随着压测线程数的增加，会得到一个QPS极限值。之后再增加线程数，会导致响应耗时上涨，而QPS不再变化。因此我们需要通过设置合理的线程数，来达到该极限值：

1、验证单个请求的响应时间（RT）

2、预估线程数 = RT x CPU核数 x 单CPU使用率 = RT x CPU核数 x 100%

6.2 耗时

客户端RT = 服务端RT + 网络开销 = CPU Time + Wait Time + 网络开销

由于使用内网压测，避免了网络开销对耗时的影响。因此这里的耗时基本上是服务端本身的响应耗时。

RT通常会随着压测线程数增加而上涨，因此这里会取QPS达到极限值时的响应耗时。TMF一般要求服务响应耗时在300ms之内。

6.3 错误率

6.4 CPU使用率

CPU使用率通常可以作为参考标准，用以判断QPS是否已达到预期极限值。假设被测环境为4核CPU，CPU使用率被压满可到400%（实际通常到380%-390%，服务器自身预留）。

如果CPU使用率未被压满，但QPS已经到达极限值，则需要排查瓶颈点。根据经验总结，瓶颈通常为后端服务。（如：压测网关，但后端转发服务耗时高）

七、测试场景

根据不同需求（被测服务）的要求，通常会选择不同的测试场景。目前TMF压测中，负载测试和稳定性测试为必选项。

7.1 基准测试

在给系统施加较低压力时，查看系统的运行状况并记录相关数据作为基础。

7.2 负载测试

是指对系统不断地增加压力或增加一定压力下的持续时间，知道系统的某项或多项性能指标达到安全临界值，例如某种资源已经达到饱和状态等。

7.3 压测测试

压力测试是评估系统处于或超过预期负载时的运行情况，关注点在于系统在峰值负载或超出最大载荷情况下的处理能力。

7.4 稳定性测试

在给系统加载一定业务压力的情况下，给系统运行一段时间，以此检测系统是否稳定。

7.5 并发测试

测试多个用户同时访问同一应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。

7.6 高耗时测试

验证后端调用服务返回耗时高的情况下，当前被压测服务的处理情况。

八、问题定位

待补充 ## 九、压测心得

压测过程出现性能瓶颈，若压测机任务管理器查看到的cpu、网络都正常，未达到90%以上，则可以说明服务器有问题，压力机没有问题
通常影响性能的因素可能包括：数据库、应用程序、中间件、网络、操作系统等
若吞吐量大于并发数，则可以慢慢的往上面增加；若压测机性能很好的情况下，出现吞吐量小于并发数，说明并发数不能再增加了，可以慢慢往下减，找到最佳的并发数
在实际的业务过程中，请求之间是有一定时间的停顿的，所以在请求之间设置合理的延时是必须的，也是更接近用户真实业务情况。除此之外，在大多数时候如果要在压测过程中完全模拟真实业务场景，还需要做大量的功能调研与用户使用调研，尽可能实现场景的真实覆盖，只有越接近真实，才能尽早挖掘出系统的瓶颈和准确评估系统的性能指标。

文档信息

本文作者：Kaka
本文链接：https://nnnnmkaka.github.io/2020/06/19/%E5%88%86%E5%B8%83%E5%BC%8F%E5%8E%8B%E6%B5%8B/
版权声明：自由转载-非商用-非衍生-保持署名（创意共享3.0许可证）