基于docker实现JMeter分布式压测

为什么需要分布式?

在工作中经常需要对一些关键接口做高QPS的压测,JMeter是由Java 语言开发,没创建一个线程(虚拟用户),JVM默认会为每个线程分配1M的堆栈内存空间。受限于单台试压机的配置很难实现太高的并发。所以,通过JMeter实现分布式,可以整合多台主机的硬件资源,实现同时对被测试接口进行压力测试。

Jmeter分布式测试环境中有两个角色:Master 和 Slaves

Master节点:向参与的Slaves节点发送测试脚本,并聚合Agent节点的执行结果。

Slaves节点:接收并执行Master节点发送过来的测试脚本,并将执行结果返回给Master。

为什么要使用docker?

如果要分布式联动每台主机,就要求每台主机都要有JMeter环境(JDK + JMeter),如果利用docker就可以通过docker管理 JMeter环境,简单的拉取镜像,启动容器即可。更进一步讲,利用k8s、云服务可以无限的扩容JMeter试压机,理论上多少的并发用户都可以模拟。

准备工作

JDK:启动 JMeter 工具需要

复制代码
$ brew install openjdk@11

JMeter: 编写JMeter脚本

https://archive.apache.org/dist/jmeter/binaries/

编写一个简单的脚本。

docker: 通过doker创建容器。

python 复制代码
$ docker pull runcare/jmeter-master
$ docker pull runcare/jmeter-slave

查看docker镜像

python 复制代码
$ docker images

REPOSITORY              TAG        IMAGE ID       CREATED         SIZE
runcare/jmeter-master   latest     e052a8cd8680   3 years ago     326MB
runcare/jmeter-slave    latest     05c7ba96d97d   3 years ago     326MB

请记住 jmeter-master 的镜像ID e052a8cd8680,后面会用到。

分布式压测使用

启动 slave 节点。

假设有两台主机,可以启动两个slave。

python 复制代码
$ docker run -it -d --name slave01 runcare/jmeter-slave
$ docker run -it -d --name slave02 runcare/jmeter-slave

查看启动的容器

python 复制代码
$ docker ps

CONTAINER ID   IMAGE                  COMMAND                   CREATED             STATUS             PORTS                 NAMES
b270636a7741   runcare/jmeter-slave   "/bin/sh -c 'jmeter-..."   43 seconds ago      Up 42 seconds      1099/tcp, 60001/tcp   slave01
2584c7fef5f8   runcare/jmeter-slave   "/bin/sh -c 'jmeter-..."   52 seconds ago      Up 50 seconds      1099/tcp, 60001/tcp   slave02

查看两个slave 的IP 地址

python 复制代码
$ docker inspect -f '{{ .Name }} => {{ .NetworkSettings.IPAddress }}' $(docker ps -q)

/slave01 => 172.17.0.3
/slave02 => 172.17.0.2
/k8s_nginx_nginx-deployment1-fc7586d97-jvjvk_nginx_4379ed7f-b0be-4f9f-a0a9-4a5fd7b45b38_1 => 
/k8s_nginx_nginx-deployment1-fc7586d97-bztbh_nginx_6968e6b1-6689-4f1a-a9ea-04532577841c_1 => 

发送压测脚本到 slave

python 复制代码
$ result=`date +"%Y%m%d%H%M%S"` && docker run --rm -v /Users/fnngj/zhpro/script:/data e052a8cd8680 jmeter -n -t /data/baidu_script.jmx -l /data/$result.jtl -j /data/$result.log -e -o /data/$result -R 172.17.0.2,172.17.0.3

参数说明

result=date +"%Y%m%d%H%M%S"`: 指定测试结果的名称,以当前日期时间命名。

/Users/fnngj/zhpro/script : 压测脚本的目录,测试结果也会存放到该目录下。

baidu_script.jmx : 压测脚本的名称,存放于 /Users/fnngj/zhpro/script目录下。

e052a8cd8680 : jmeter-master 的镜像ID。

172.17.0.2,172.17.0.3 :两台 slave 的IP 地址。

测试结果

执行完的目录

python 复制代码
$ pwd
/Users/fnngj/zhpro/script

$ ls
20230707005328     20230707005328.jtl 20230707005328.log baidu_script.jmx

查看报告

进入20230707005328 目录,点击 index.html 文件,可以看到压测的结果。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

相关推荐
lsc_blog2 小时前
听到优化风声,先准备能由自己掌控的事
数据库·分布式·中间件·职场和发展·重构
Lansonli1 天前
大数据Spark(八十七):Spark-Submit 参数详解
大数据·分布式·spark
qq_452396231 天前
第二篇:《CommitLog + ConsumeQueue:一条日志解决 Kafka 多分区随机写的难题》
分布式·kafka
专注仿真1 天前
自动化测试实战项目开发:从零搭建一套可落地的测试框架
自动化测试
Alluxio2 天前
Alluxio + OCI:为 AI 工作负载实现亚毫秒访问延迟与可扩展吞吐
运维·数据库·人工智能·分布式·缓存·ai·语言模型
阿卡好可爱2 天前
Lua 热更新不生效:改完文件线上仍是旧逻辑,package.loaded 与 upvalue 重绑定详解
数据结构·分布式·后端·架构·lua
秋天的怀念_David3 天前
算法一千零一夜 · 第二十八夜 注册
java·程序人生·算法
方方洛4 天前
ray教程-28-附录G-CICD与Slurm与云上调度
人工智能·分布式·机器学习
空奈qwq4 天前
【Kafka 从入门到实战】从手写一个队列到生产级消息中间件:架构、分区、消费组、零拷贝全解析
分布式·架构·kafka