跳至主要內容

搭建压测监控平台

Cactus li2024年11月26日...大约 12 分钟项目性能优化项目性能优化

本章介绍如何使用Docker 容器来搭建压力测试监控平台。

1. 安装容器及服务

1.1 安装Docker容器

利用脚本进行安装

curl -sSL https://get.docker.com/ | sh
sudo chmod 777 /var/run/docker.sock

关于Docker 相关内容请看 Docker命令记录

1.2 安装配置InfluxDB

1.2.1 启动InfluxDB

docker pull influxdb:latest

启动InfluxDB的容器,并将端口 8083 和 8086 映射出来:

docker run -d --name influxdb \
 -p 8086:8086 \
 -p 8083:8083  \
 -v /sg-work/influxDB/influxdb_data:/var/lib/influxdb \
 influxdb:latest

-d:在后台运行容器。

--name influxdb:为容器指定一个名称。

-p 8086:8086:将主机的 8086 端口映射到容器的 8086 端口。

-v influxdb_data:/var/lib/influxdb:将数据持久化到 Docker 卷中。

创建完成后在浏览器输入:http://192.168.1.20:8086/ 进入访问控制,创建用户、创建组织和桶。

image-20241128160050037
image-20241128160050037
image-20241128160350616
image-20241128160350616

把密钥复制下来进行保存。

image-20241128160754857
image-20241128160754857

红框标记处就是在初始化用户时创建的桶。

1.2.2 安装 influx-cli 并创建 jmeter 数据库

创建相应目录,下载压缩包,解压包获取二进制运行文件 flux:

mkdir ../influx-cli && cd $_

# amd64
wget https://download.influxdata.com/influxdb/releases/influxdb2-client-2.7.5-linux-amd64.tar.gz


tar -xf influxdb2-client-2.7.5-linux-amd64.tar.gz

创建 config 方便操作 InfluxDB,创建 jmeter 数据库。

官方文档:https://docs.influxdata.com/influxdb/v2/reference/cli/influx/config/create/

./influx config create --config-name influx-cli-config \
--host-url http://127.0.0.1:8086 \
--org cactusli \
--token IU5YpbBDiFOI7Oby99vdpEjRwgZpL1H2x33dmQXj29rQpYMKfMsC7LrbDaZNwZB609xekP0aGN7KTq_== \
--active

# bucket-id桶的id 在控制面板中获取
./influx v1 dbrp create \
  --bucket-id 1496dfd1f8047672 \
  --db jmeter \
  --rp jmeter \
  --default
  
# 查询现有数据库
./influx v1 dbrp list

# 根据数据库ID删除数据库
./influx v1 dbrp delete --id 0e08848aa8d8b000

1.2.3 配置JMeter脚本后置监听器

配置后置监听器,把 jmeter 性能测试数据写入 influxdb桶中,目前使用的 InfluxDB 2.x 版本,需要配置后端监听器支持 InfluxDB 2.x 的实现。

访问 Github 下载实现支持的 Jar, 然后放入到 /jmeter-xxx/lib/ext 目录下,最后重启 Jmeter,操作步骤如下。

下载地址:jmeter-influxdb2-listener-plugin

image-20241129142639405
image-20241129142639405
image-20241128172431400
image-20241128172431400
image-20241129152206030
image-20241129152206030

配置参数含义详细见:https://github.com/mderevyankoaqa/jmeter-influxdb2-listener-plugin

1.2.4 运行压测脚本验证

运行 Jmeter 脚本,然后再次在 influxdb 中查看数据,发现类似下面的数据说明输入导入成功:

# orgID是 通过 ./influx v1 dbrp list 命令查询出来的
curl --request POST \
  http://192.168.1.20:8086/api/v2/query?orgID=cb6ceb3bf996931e  \
  --header 'Authorization: Token IU5YpbBDiFOI7Oby99vdpEjRwgZpL1H2x33dmQXj29rQpYMKfMsC7LrbDaZNwZB609xekP0aGN7KTq_98Wtc0w==' \
  --header 'Accept: application/csv' \
  --header 'Content-type: application/vnd.flux' \
  --data 'from(bucket:"jmeter")
        |> range(start: -35m)
        |> limit(n: 2)'

官方文档:https://docs.influxdata.com/influxdb/v2/query-data/execute-queries/influx-api/

image-20241129150259752
image-20241129150259752

可以查看到写入数据库中的最新数据:

image-20241129150904294
image-20241129150904294

删除指定范围的数据:

./influx delete \
  --bucket jmeter \
  --start 2024-11-28T00:00:00Z \
  --stop 2025-11-30T00:00:00Z

1.3 安装配Grafana

下载Grafana镜像:

docker pull grafana/grafana

启动Grafana容器:

docker run -d --name grafana -p 3000:3000 grafana/grafana

浏览器访问: http://192.168.1.20:3000/login

默认账户密码:admin / admin

选择添加数据源:

image-20241128175042660
image-20241128175042660

找到并选择 influxdb :

image-20241128175142944
image-20241128175142944

配置数据源:

image-20241128175830270
image-20241128175830270

导入模板:

image-20241128180954478
image-20241128180954478

模板导入的3种方式:

image-20241128181157165
image-20241128181157165

在Grafana的官网找到我们需要的展示模板:

输入模板ID 13644进行 load, 选中创建的数据源进行导入。

image-20241129151320234
image-20241129151320234

导入模板成功后就会看到如下界面:

image-20241129152106248
image-20241129152106248

1.4 安装安装 node_exporter

node-exporter使用Go语言编写,它主要用来监控主机系统的各项性能参数,可收集各种主机指标的库,还提供了textfile功能,用于自定义指标。

1.4.1 二进制安装

# 创建目录
mkdir node_exporter && cd node_exporter

# 下载二进制包
wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz

# 解压并进入目录
tar -xvf node_exporter-1.8.2.linux-amd64.tar.gz && cd node_exporter-1.8.2.linux-amd64

# 后台运行
nohup ./node_exporter > node.log 2>&1 &

访问 :http://192.168.1.20:9100/metrics

image-20241129162121988
image-20241129162121988

1.4.2 Docker安装

官方不建议通过Docker方式部署node-exporter,因为它需要访问主机系统。 通过docker部署的方式,需要把任何非根安装点都绑定到容器中,并通过--path.rootfs参数指定。

docker run -d --net="host" --pid="host" -v "/:/host:ro,rslave" prom/node-exporter --path.rootfs=/host

部署完成后,访问节点地址:http://ip:9100/metrics ,可看到node-exporter获取的指标。

1.4.3 配置node-exporter

node-exporter提供不少配置参数,可使用 --help 进行查看。 $ ./node_exporter --help

例如:通过--web.listen-address 改变监听的端口

./node_exporter --web.listen-address=":8080" &

如果需要收集主机上面运行服务的状态,可启用systemd收集器。由于systemd指标较多,可以用--collector.systemd.unit-include参数配置只收集指定的服务,减少无用数据,该参数支持正则表达式匹配。如docker和ssh服务状态,

示例:./node_exporter --collector.systemd --collector.systemd.unit-include="(docker|sshd).service" &

如果只想启用需要的收集器,其他的全部禁用,可用如下格式配置

--collector.disable-defaults --collector.<name>

1.5 安装Prometheus

Prometheus是一款近年来非常火热的容器监控系统,它使用go语言开发,设计思路来源于Google的Borgmom(一个监控容器平台的系统)。

产品由前谷歌SRE Matt T.Proudd发起开发,并在其加入SoundCloud公司后,与另一位工程师Julius Volz合伙推出,将其开源发布。

2016年,由Google发起的原生云基金会(Cloud Native Computing Foundation)将Prometheus纳入麾下,成为该基金会继Kubernetes后第二大开源项目。

Prometheus天然具有对容器的适配性,可非常方便的满足容器的监控需求,也可用来监控传统资源。近年来随着kubernetes容器平台的火爆,Prometheus的热度也在不断上升,大有超越老牌监控系统Zabbix成为No.1的趋势,目前已在众多公司得到广泛的使用。

1.5.1 二进制安装

创建目录:

mkdir prometheus && cd prometheus
# 下载安装包
wget  https://github.com/prometheus/prometheus/releases/download/v3.0.1/prometheus-3.0.1.linux-386.tar.gz
# 解压tar包并进入目录
tar -xvf prometheus-3.0.1.linux-386.tar.gz && cd prometheus-3.0.1.linux-386

运行--version 检查版本

root@xx:/sg-work/prometheus/prometheus-3.0.1.linux-386# ./prometheus --version
prometheus, version 3.0.1 (branch: HEAD, revision: 1f56e8492c31a558ccea833027db4bd7f8b6d0e9)
  build user:       root@e249152d3bff
  build date:       20241128-17:26:10
  go version:       go1.23.3
  platform:         linux/386
  tags:             netgo,builtinassets,stringlabels

编辑配置文件:

vim /sg-work/prometheus/prometheus-3.0.1.linux-386/prometheus.yml
global:
  scrape_interval:     15s 
  evaluation_interval: 15s 
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

启动Prometheus,并指定配置文件:

nohup ./prometheus --config.file /sg-work/prometheus/prometheus-3.0.1.linux-386/prometheus.yml >  prometheus.log 2>&1 &

注意:Prometheus默认只保留15天的监控数据,可通过--storage.tsdb.retention选项控制时间序列的保留时间;--storage.tsdb.path选项可用于控制时间序列数据库位置,默认数据目录位于运行Prometheus的目录中。

1.5.2 Docker安装

docker的安装方式很简单,只需要一条命令即可

docker run --name prometheus -d -p 9090:9090 prom/prometheus

如果要将配置文件与容器分离,可将prometheus.yml文件保存在本地目录 ,在启动时通过-v参数挂载到容器上面

mkdir prometheus && cd prometheus

vim /etc/prometheus/prometheus.yml
global:
  scrape_interval:     15s 
  evaluation_interval: 15s 
alerting:
  alertmanagers:
  - static_configs:
    - targets:
rule_files:
scrape_configs:
  - job_name: 'prometheus'
    static_configs:
    - targets: ['localhost:9090']

启动容器:

docker run --name prometheus -d -p 9090:9090 \
-v /sg-work/prometheus/prometheus-3.0.1.linux-386/prometheus.yml:/etc/prometheus/prometheus.yml \
prom/prometheus

启动完成后,打开浏览器,访问http://192.168.1.20:9090/targets 可看到系统界面。

image-20241129170505585
image-20241129170505585

1.6 在Grafana中配置Prometheus的数据源

image-20241129170820256
image-20241129170820256

Grafana导入Linux展示模板 :

image-20241204093310917
image-20241204093310917
image-20241203172729811
image-20241203172729811

2. 梯度压测:分析接口性能瓶颈

分析接口性能瓶颈,主要指标有【响应时间、并发用户数、吞吐量、资源使用率】她们之间存在一定的相关性,共同感应出性能的不同方面。

image-20241204163244728
image-20241204163244728

在 Jmeter 中执行一次测试接口如下:

http://218.249.73.244:48080/web-api/web/gateway/newsPage?userId=&pageNo=1&pageSize=10&status=6
image-20250116093624886
image-20250116093624886

响应时间30ms,响应数据包190.23kb,请求数据包19.49kb

2.1 模拟低延时场景

用户访问接口并发逐渐增加的过程,预计接口的响应时间为30ms.

2.2 压测机器环境配置

单位全称换算关系
MbpsMegabit per second网络速度的单位
MB/sMegabyte per second数据传输的单位
1 byte1 字节等于 8 bits
1 bit1 位等于 0.125 bytes
1 megabit1 兆位等于 1,000,000 bits
1 megabyte1 兆字节等于 1,000,000 bytes
1 megabit转换为 megabytes等于 0.125 megabytes
1 Mbps转换为 MB/s等于 0.125 MB/s

结论:

1 Gbit/s = 1 Gbps = 125 MB/s

1 Mbps = 0.125 MB/s

2.3 配置监听器

聚合报告

查看结果树

活动线程数

TPS统计分析

RT统计分析

配置监听器

压测监控平台

2.4 性能瓶颈剖析

2.4.1 梯度压测,测出瓶颈

通过逐步提升压力,测试性能瓶颈:

线程数循环次数样本总数
550002.5 万个样本
1050005 万个样本
1550007.5 万个样本
20500010 万个样本
25500012.5 万个样本
30500015 万个样本
35500017.5 万个样本
40500020 万个样本

梯度压测后的聚合报告

image-20250110171117493
image-20250110171117493

Active Threads

image-20250110171325749
image-20250110171325749

RT

image-20250110171403407
image-20250110171403407

TPS

image-20250110171505422
image-20250110171505422

压测监控平台与JMeter压测结果一致

image-20250110171647474
image-20250110171647474

压测中服务器监控指标

image-20250110171815666
image-20250110171815666

2.4.2 问题1:网络到达瓶颈

image-20250110171854643
image-20250110171854643
image-20250110172016136
image-20250110172016136

**结论:**随着压力的上升,TPS不再增加,接口响应时间逐渐在增加,偶尔出现异常,瓶颈凸显。系统的 负载不高。CPU、内存正常,说明系统这部分资源利用率不高。带宽带宽显然已经触顶了。

优化之后的解决方案:

优化之后效果,基于方案01-降低接口响应数据包大小,压测结果如下图所示:

image-20250113111531702
image-20250113111531702
image-20250113141414224
image-20250113141414224
image-20250113141901843
image-20250113141901843
image-20250113141949130
image-20250113141949130

方案02-提升带宽【或者在内网压测】

提升自己测试机器的网络宽带,或在机器内网进行压测!

问题:可不可以基于RT与TPS算出服务端并发线程数?

服务端线程数计算公式:TPS/ (1000ms/ RT均值)

结论:

2.4.3 问题2:接口的响应时间是否正常?是不是所有的接口响应都可以这么快?

情况02-模拟高延时场景,用户访问接口并发逐渐增加的过程。接口的响应时间为500ms;

    @GetMapping("/newsPage")
    @Operation(summary = "前端门户获得新闻分页")
    public CommonResult<PageResult<NewsPageWebReqVO>> getNewsPage(@Valid NewsSelectWebReqVO pageReqVO) {
        //查询已发布的新闻
        pageReqVO.setAuditStatus(1);
        PageResult<NewsDO> pageResult = webService.selectWebNewsPage(pageReqVO);
        try {
            //休眠500ms
            TimeUnit.MILLISECONDS.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return success(BeanUtils.toBean(pageResult, NewsPageWebReqVO.class));
    }

响应慢接口:500ms+,响应数据包73kb,请求数据包42kb

http://218.249.73.244:48080/web-api/web/gateway/newsPage?userId=&pageNo=1&pageSize=1&status=6

测试结果:RT、TPS、网络IO、CPU、内存、磁盘IO

image-20250116164947797
image-20250116164947797
image-20250116165141680
image-20250116165141680
image-20250116165211978
image-20250116165211978

最后结论

2.4.4 问题3:TPS在上升到一定的值之后,异常率较高

评论
  • 按正序
  • 按倒序
  • 按热度
Powered by Waline v3.5.0