基于Jmeter的分布式压测实践

简介: 本文主要介绍:1.Jmeter集合点用法;2.Jmeter命令行参数详解;3.Jmeter分布式部署方案;4.Jmeter分布式调度原理;5.Jmeter分布式部署过程;Jmeter分布式压测业务系统登录接口实践;

写在前面

平时在使用Jmeter做压力测试的过程中,由于单机的并发能力有限,所以常常无法满足压力测试的需求。因此,Jmeter还提供了分布式的解决方案。本文是一次利用Jmeter分布式对业务系统登录接口做的压力测试的实践记录。按照惯例,在正式开始前,先简单介绍一下本文大纲:

  • Jmeter集合点用法
  • Jmeter命令行参数详解
  • Jmeter分布式部署方案
  • Jmeter分布式调度原理
  • Jmeter分布式部署过程
  • Jmeter分布式压测业务系统登录接口实践

一、Jmeter集合点用法

集合点是使用Jmeter进行压力测试中一个绕不开的话题。

集合点通俗地理解就是,例如要模拟100个并发用户,集合点会将这100个线程集结完毕后,统一释放,同时对系统进行施压。Jmeter中可以通过同步定时器 Synchronizing Timer 来完成:

同步定时器中”模拟用户组的数量“与线程组的线程数量的关系:

1.当模拟用户组的数量 = 线程组的线程数量

例如数量都是5,那么运行测试,Jmeter会等到5个用户同时准备好后,并发发起请求;

2.当模拟用户组的数量 < 线程组的线程数量

① 未设置超时时间

例如:模拟用户为5,线程数量为8,那么在运行Jmeter后,Jmeter会先同时发起5个请求,剩下3个用户不足集合点的数量5,由于又没有设置超时时间,因此达不到集合点的数量要求,Jmeter就会一直处于等待状态;

② 已设置超时时间

例如:模拟用户为5,线程数量为8,超时时间设置为3000(以毫秒为单位,即3秒)

那么在运行Jmeter后,Jmeter会先同时发起5个请求,由于剩下3个用户不足集合点要求的数量5,因此会超时等待3秒钟,在3秒钟后再同时发起剩下的3个用户的请求,共8个用户;

3.当模拟用户组的数量 > 线程组的线程数量

① 未设置超时时间

例如:模拟用户为8,线程数量为5,超时时间为0

由于设置的模拟用户数量为8,即集合点数量为8,而线程组的总用户数只有5,因此达不到集合点数量要求,且又没有设置超时时间,所以Jmeter会一直处于等待状态,不会发起任何请求,如下图所示:

② 已设置超时时间

例如:模拟用户为5,线程数量为8,超时时间设置为3000(以毫秒为单位,即3秒)

由于设置的模拟用户数量为8,即集合点数量为8,而线程组的总用户数只有5,因此达不到集合点数量要求,但是设置了超时时间为3秒,所以Jmeter会在3秒后,同时发起5个(用户)请求,如下图所示:

二、Jmeter命令行参数详解

参数

作用

-n

表示在命令行模式下运行 JMeter

-t

指定脚本文件

-R

指定从节点(agent)执行测试,多个ip用逗号隔开

-r

表示启动全部agent

-f

表示每次都会清空前一次的执行结果,写入新的结果

-l

生成测试结果文件,默认以 jtl 结尾

-e

生成测试报告

-o

指定生成测告的位置,必须为空

-g

指定已存在的jtl结尾的测试文件生成报告

常见用法:

./jmeter.bat -n-t test.jmx  # 以命令行方式运行test.jmx脚本./jmeter.bar -n-t test.jmx -l test.jtl  # 以命令行方式运行test.jmx脚本,并生成测试结果文件test.jtl./jmeter.bar -n-t test.jmx -f-l test.jtl -e-o report # 以命令行方式运行test.jmx脚本,每次生成结果前先清空test.jtl,同时在report目录下生成测试报告./jmeter.bar -n-t test.jmx -l test.jtl -R192.168.1.122  # 指定远程主机192.168.1.122执行测试

三、Jmeter分布式部署方案

主机

IP地址

Master主节点(Windows)

192.168.1.131

Slave从节点-1(Linux)

192.168.1.121

Slave从节点-2(Linux)

192.168.1.122

Slave从节点-3(Linux)

192.168.1.123

注意事项:

  • 主节点及各个从节点机器必须提前安装好Java环境;
  • 主节点及各个从节点的Jmeter版本保持统一
  • master会在发送测试计划时将jmx的脚本文件发送到各个从节点,因此,脚本文件不用手动上传到各个从节点;
  • 但是master不会将外部文件一起发送,所以在测试中用到的CSV等参数化文件,需要把CSV等文件手动上传到各个从节点,最好都放置在bin目录下,Jmeter会直接从bin目录下开始查找;

四、Jmeter分布式调度原理

1.各节点作用

  • 主节点:主要负责管理从节点(负载机)、分配调度任务(脚本分发)、收集测试结果
  • 从节点:执行测试任务,模拟并发请求

2.工作流程

① 主节点负责将测试任务、测试脚本下发给各个从节点;

② 从节点接收到测试任务后,开始驱动各自环境上的Jmeter执行测试任务、模拟并发请求;

③ 从节点执行完成后会将测试结果回传给主节点;

④ 最后主节点将各个从节点的收集回来的测试结果进行展示;

五、Jmeter分布式部署过程

1.主节点部署

① 编辑主节点jmeter.properties配置文件

  • 第268行,remote_hosts添加从节点主机地址,多个从节点用逗号隔开(注意:不同版本可能存在差异)
  • 第272行,为主节点端口号,如有端口占用,可手动修改
  • 第345行,server.rmi.ssl.disable由false改为true(关闭ssl)

② 主节点启动jmeter-server服务

Windows环境下直接点击运行Jmeter的bin目录下的jmeter-server.bat即可,启动成功会出现如下提示:

2.从节点部署

① 将Jmeter压缩包上传到各个从节点并解压

从节点均为Linux环境,解压命令为:

unzip apache-jmeter.zip

② 修改jmeter.properties配置文件

  • 第345行,server.rmi.ssl.disable由false改为true(关闭ssl)

③ 启动jmeter-server服务

chmod-R+x bin # jmeter-server、jmeter文件都需要执行权限,可以简单粗暴使用chmod -R参数赋予整个bin目录执行权限 ./jmeter-server # 启动jmeter-server服务

启动成功会出现如下提示:

3.测试主节点与从节点的连通性

可以通过Jmeter工具-运行-远程启动,选择一个从节点;也可以使用命令行-R参数指定一个从节点运行:

如下图所示,Starting...表示主节点已将任务下发到指定的从节点,从节点开始执行测试任务

4.Jmeter分布式部署常见问题及报错解决

1)启动远程主机,提示“Engine is busy - please try later”

原因:本地或者远程负载机,未正常关闭

解决:杀掉进程重新启动(可以观察主节点及从节点的jmeter-server日志,如果只有Starting,没有Finished,那么大概率是这台机器出现了问题)

2)主节点发起测试后未接收到结果数据

如:执行成功后,察看结果树无数据,主节点及从节点也没有任何报错

原因:测试脚本中有参数化,远程节点上参数化csv文件跟本地测试中设置的目录不一致,或从节点上缺少csv文件

解决:将csv文件分别上传一份到各个从节点,csv文件最好设置相对路径,不要设置绝对路径,将csv文件存放在bin目录下

3)Jmeter启动从节点运行测试报错“connection refused”

原因:从节点未启动jmeter-server服务

解决:各个从节点均启动jmeter-server服务

六、Jmeter压测业务系统登录接口实践

  • 最大并发量:和我们业务系统负责人交流后,得知系统理论上支持6000~7000个左右的用户同时并发登录是没有问题的;
  • 测试的目标:测试出业务系统是否如他提供的数据、支持那么大的用户并发登录;
  • 实测数据:3台负载机,每台启动500个线程,共1500个用户并发,测试结果如下,各个负载机模拟的用户均登录正常、无报错,被测业务系统所在服务器内存、CPU均无大的波动;

  • 升压:并发用户数量1500、2100左右,系统响应都比较稳定,当并发用户量达到每台1000,一共3000个用户同时请求时,部分用户登录会返回500,总体失败率在3%左右(预测当并发用户数达到更大规模4000、5000、6000,失败的比例还会增大)

小结

  • 以上就是利用Jmeter实现分布式压测的一次实践,确切的说应该是初探;
  • 在压力测试过程中,CPU和内存的动态变化我并没有做详细的监控,后续准备借助JMeter+InfluxDB+Grafana的监控组合来可视化监控测试过程;
  • 性能测试是一个庞大的工程和命题,性能测试工具仅仅是实现性能测试的技术手段,会使用性能测试工具不代表就掌握了性能测试;
  • 所有使用性能测试工具的目的都只是为了模拟压力的发起,在性能测试过程中,工具仅仅起到脚本开发、场景实现、测试执行等作用,而性能测试还包括需求获取、场景设计、结果分析和调优等诸多环节,最终还是要靠人来实现;
  • 尤其是性能瓶颈分析和调优,除了依赖性能测试结果外,还需要依赖于人的强大的性能测试功底,以及对业务、对系统架构的了解;
相关文章
|
数据采集 监控 机器人
浅谈网页端IM技术及相关测试方法实践(包括WebSocket性能测试)
最开始转转的客服系统体系如IM、工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务,以及客服的效率等都产生了诸多限制,所以我们决定自研替换第三方系统。下面主要分享一下网页端IM技术及相关测试方法,我们先从了解IM系统和WebSocket开始。
329 4
|
3月前
|
人工智能 安全 Java
分布式 Multi Agent 安全高可用探索与实践
在人工智能加速发展的今天,AI Agent 正在成为推动“人工智能+”战略落地的核心引擎。无论是技术趋势还是政策导向,都预示着一场深刻的变革正在发生。如果你也在探索 Agent 的应用场景,欢迎关注 AgentScope 项目,或尝试使用阿里云 MSE + Higress + Nacos 构建属于你的 AI 原生应用。一起,走进智能体的新世界。
913 59
|
3月前
|
关系型数据库 Apache 微服务
《聊聊分布式》分布式系统基石:深入理解CAP理论及其工程实践
CAP理论指出分布式系统中一致性、可用性、分区容错性三者不可兼得,必须根据业务需求进行权衡。实际应用中,不同场景选择不同策略:金融系统重一致(CP),社交应用重可用(AP),内网系统可选CA。现代架构更趋向动态调整与混合策略,灵活应对复杂需求。
|
5月前
|
数据采集 消息中间件 监控
单机与分布式:社交媒体热点采集的实践经验
在舆情监控与数据分析中,单机脚本适合小规模采集如微博热榜,而小红书等大规模、高时效性需求则需分布式架构。通过Redis队列、代理IP与多节点协作,可提升采集效率与稳定性,适应数据规模与变化速度。架构选择应根据实际需求,兼顾扩展性与维护成本。
148 2
|
8月前
|
人工智能 安全 应用服务中间件
阿里巴巴 MCP 分布式落地实践:快速转换 HSF 到 MCP server
本文分享了阿里巴巴内部将大规模HSF服务快速转换为MCP Server的实践经验,通过Higress网关实现MCP协议卸载,无需修改代码即可接入MCP生态。文章分析了MCP生态面临的挑战,如协议快速迭代和SDK不稳定性,并详细介绍了操作步骤及组件功能。强调MCP虽非终极解决方案,但作为AI业务工程化的起点具有重要意义。最后总结指出,MCP只是AI原生应用发展的第一步,未来还有更多可能性值得探索。
1335 48
|
4月前
|
消息中间件 缓存 监控
中间件架构设计与实践:构建高性能分布式系统的核心基石
摘要 本文系统探讨了中间件技术及其在分布式系统中的核心价值。作者首先定义了中间件作为连接系统组件的&quot;神经网络&quot;,强调其在数据传输、系统稳定性和扩展性中的关键作用。随后详细分类了中间件体系,包括通信中间件(如RabbitMQ/Kafka)、数据中间件(如Redis/MyCAT)等类型。文章重点剖析了消息中间件的实现机制,通过Spring Boot代码示例展示了消息生产者的完整实现,涵盖消息ID生成、持久化、批量发送及重试机制等关键技术点。最后,作者指出中间件架构设计对系统性能的决定性影响,
|
8月前
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
2879 57
|
8月前
|
安全 JavaScript 前端开发
HarmonyOS NEXT~HarmonyOS 语言仓颉:下一代分布式开发语言的技术解析与应用实践
HarmonyOS语言仓颉是华为专为HarmonyOS生态系统设计的新型编程语言,旨在解决分布式环境下的开发挑战。它以“编码创造”为理念,具备分布式原生、高性能与高效率、安全可靠三大核心特性。仓颉语言通过内置分布式能力简化跨设备开发,提供统一的编程模型和开发体验。文章从语言基础、关键特性、开发实践及未来展望四个方面剖析其技术优势,助力开发者掌握这一新兴工具,构建全场景分布式应用。
816 35
|
7月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
1156 23
|
9月前
|
监控 测试技术 数据库连接
利用 RunnerGo 深度探索 API 性能测试:从理论到实践
API性能测试是保障应用稳定性和用户体验的关键环节。本文详细探讨了如何使用RunnerGo全栈测试平台进行高效API性能测试,涵盖测试计划创建、场景设计、参数配置到执行与分析全过程。通过电商平台促销活动案例,展示了高并发下的测试策略与优化措施,如代码与数据库查询优化、数据库连接池扩容、服务器资源配置调整及缓存策略实施等。最终显著提升系统性能,满足高并发需求。API性能测试需持续关注与优化,以适应业务发展和用户需求变化。
329 33