针对性能测试工具Gatling与Jmeter的比较及看法

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 对于Gatling的优点网上也总结了很多,我也不多说,但是光从测试场景配置上来说,Gatling就不输Loadrunner......
版权声明:本文为博主原创文章,未经博主允许不得转载。欢迎访问我的博客 https://blog.csdn.net/smooth00/article/details/80014622

我是一个用惯Loadrunner的人,由于Loadrunner过于重量级,不方便在云端部署和使用,所以平常在这方面只能选择Jmeter,Jmeter的开源性和轻量化是我最喜欢的地方,但是Jmeter的脚本开发模式是我最不喜欢的地方:jmx脚本对应的XML格式太不直观,不方便维护和管理,代码调试也不方便(对于我们这些不愿意依赖于脚本录制的人来说,这点很重要),另外不喜欢的就是Jmeter的性能和稳定性,即使用了Non-GUI + 分布式压测的模式,Master节点的承受能力也不如Loadrunner。

        所以我真的比较倾向于找一款既能像Loadrunner那样高性能高稳定性,代码维护管理自如,又能像Jmeter那样轻量级的、高扩展性的测试工具。目前来看好像不存在这种工具,但是有一款性能测试工具叫Gatling,与Jmeter进行分析比较了一下,觉得它很有潜力,兴许哪一天,它借鉴了Jmeter的一些优点,就达到了我的要求,或者Jmeter借鉴一下它,做个翻天腹地的改造,那也未尝不可。


        对于Gatling的优点网上也总结了很多,我也不多说,但是光从测试场景配置上来说,Gatling就不输Loadrunner,拿例子来说明:

setUp(  
  scn.inject(  
    nothingFor(4 seconds), // 场景1  
    atOnceUsers(10), // 场景2  
    rampUsers(10) over(5 seconds), // 场景3  
    constantUsersPerSec(20) during(15 seconds), // 场景4  
    constantUsersPerSec(20) during(15 seconds) randomized, // 场景5  
    rampUsersPerSec(10) to(20) during(10 minutes), // 场景6  
    rampUsersPerSec(10) to(20) during(10 minutes) randomized, // 场景7  
    splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(10 seconds), // 场景8  
    splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(atOnceUsers(30)), // 场景9  
    heavisideUsers(100) over(20 seconds) // 场景10  
    ).protocols(httpConf)  
  )  

以上代码包含了10个场景的例子:

1. nothingFor(4 seconds) 
   在指定的时间段(4 seconds)内什么都不干
2. atOnceUsers(10)
   一次模拟的用户数量(10)。
3. rampUsers(10) over(5 seconds)
   在指定的时间段(5 seconds)内逐渐增加用户数到指定的数量(10)。
4. constantUsersPerSec(10) during(20 seconds)
   以固定的速度模拟用户,指定每秒模拟的用户数(10),指定模拟测试时间长度(20 seconds)。
5. constantUsersPerSec(10) during(20 seconds) randomized
   以固定的速度模拟用户,指定每秒模拟的用户数(10),指定模拟时间段(20 seconds)。用户数将在随机被随机模拟(毫秒级别)。
6. rampUsersPerSec(10) to (20) during(20 seconds)
   在指定的时间(20 seconds)内,使每秒模拟的用户从数量1(10)逐渐增加到数量2(20),速度匀速。
7. rampUsersPerSec(10) to (20) during(20 seconds) randomized
   在指定的时间(20 seconds)内,使每秒模拟的用户从数量1(10)增加到数量2(20),速度随机。
8. splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(10 seconds) 
   反复执行所定义的模拟步骤(rampUsers(10) over(10 seconds)),每次暂停指定的时间(10 seconds),直到总数达到指定的数量(100)
9. splitUsers(100) into(rampUsers(10) over(10 seconds)) separatedBy(atOnceUsers(30))
   反复依次执行所定义的模拟步骤1(rampUsers(10) over(10 seconds))和模拟步骤2(atOnceUsers(30)),直到总数达到指定的数量(100)左右
10. heavisideUsers(100) over(10 seconds)  
  在指定的时间(10 seconds)内使用类似单位阶跃函数的方法逐渐增加模拟并发的用户,直到总数达到指定的数量(100).简单说就是每秒并发用户数递增。

就拿场景8来说,可以制造一种波浪型压力,非常适合模拟一种脉冲式的压力测试或是某类稳定性测试(压力按波峰波谷有规律的分布),如下所示:


------------------------------------------------------------------------------------------------------------------

        虽然Gatling很让我们惊奇,但就目前来说,还远没有达到我们的最佳选择,不过研究它已经非常有必要了,毕竟一个好工具的普及不是一天两天的事。Jmeter有那么多不如意的地方,但我们还得继续用呀,现在脚本的易维护性方面还不是最重要的问题,最紧迫的是如何对Jmeter进行减负,以实现稳定超高并发测试,目前只能考虑以下的方式进行:

减负一,优化监听(GUI模式,尽量不考虑)
1.“查看结果树”,需要勾选“仅日志错误”,这样只会保存错误日志到内存,数据不会多。如果保存所有,那么会保存每个请求信息和相关信息,而且这些数据都是保存到jvm内存的,且常驻数据无法回收,上万十万大量请求很快就会压垮jmeter。
2.“聚合报告”中小并(100以内)发可以保留;高并发去掉,添加“Simple Data Writer”且保存csv格式数据。“聚合报告”是非常消耗cpu的。
3.其他监听组件可以都去掉,测试完后通过保存的结果,线下生成图表报告

减负二,优化监听(Non-GUI命令行模式)
1.“查看结果树”,需要勾选“仅日志错误”,需要设置路径,保存错误信息到文件,并且保存所有信息(点击Configure,勾选所有非CSV选项)
2.“聚合报告”命令行下无效
3. 其他监听组件可以都去掉,基本在Non-GUI下无效

减负三,结果文件优化
1. 结果数据一定要保存为CSV格式(比起xml格式,每条数据会少很多)(可以用Non-GUI命令指定csv日志保存)
2.“查看结果树”保存的错误信息要保存为xml,可以保存完整结果信息,方便错误分析

减负四,如果要超高并发建议不要直接使用分布式压测
1. jmeter分布部署只是缓解问题,没根本解决问题,高并发时master机器承受的压力很大,形成单点,无法在高并发时提供稳定负载
2. 数据会写可能丢失
3. 解决方法:需要手工运行slave,或利用jenkins同时触发多台slave

减负五,再强调一下,建议用Non-GUI命令行模式运行,并且选择Linux环境运行Jmeter也是很有必要的
1. 用Non-GUI运行jmeter生成csv报告,但别输出html报告(需要高jvm内存来完成,所以分成两步进行)
2. 修改jmeter的jvm内存(建议物理内存的一半,HEAP的xms和xmx,1G的csv报告建议对应2G的xmx大小),用高jvm内存来转换csv报告至html报告(内存不够就换机器来转换报告)

减负六,可以选择用Jmeter + Grafana + InfluxDB的方式,来代替报告文件的生成,参考我的另一篇文章《关于Jmeter长时间压测的可视化监控报告
1. 将Jmeter分布式集群去中心化,Master节点不再负责收集和处理测试数据,只负责调度slave节点
2. 支持多Master-slave,形成多路Jmeter测试集群(利用Jenkins或其他调度工具同时触发调度测试)

目录
相关文章
|
9天前
|
Java 测试技术 API
自动化测试工具集成及实践
自动化测试用例的覆盖度及关键点最佳实践、自动化测试工具、集成方法、自动化脚本编写等(兼容多语言(Java、Python、Go、C++、C#等)、多框架(Spring、React、Vue等))
41 6
|
1月前
|
前端开发 Java jenkins
Jmeter压力测试工具全面教程和使用技巧。
JMeter是一个能够模拟高并发请求以检查应用程序各方面性能的工具,包括但不限于前端页面、后端服务及数据库系统。熟练使用JMeter不仅能够帮助发现性能瓶颈,还能在软件开发早期就预测系统在面对真实用户压力时的表现,确保软件质量和用户体验。在上述介绍的基础上,建议读者结合官方文档和社区最佳实践,持续深入学习和应用。
474 10
|
1月前
|
监控 Java 数据挖掘
利用Jmeter工具进行HTTP接口的性能测试操作
基础上述步骤反复迭代调整直至满足预期目标达成满意水平结束本轮压力评估周期进入常态监控阶段持续关注系统运转状态及时发现处理新出现问题保障服务稳定高效运作
277 0
|
2月前
|
敏捷开发 运维 数据可视化
DevOps看板工具中的协作功能:如何打破开发、测试与运维之间的沟通壁垒
在DevOps实践中,看板工具通过可视化任务管理和自动化流程,提升开发与运维团队的协作效率。它支持敏捷开发、持续交付,助力团队高效应对需求变化,实现跨职能协作与流程优化。
|
3月前
|
数据可视化 测试技术 Go
Go 语言测试与调试:`go test` 工具用法
`go test` 是 Go 语言内置的测试工具,支持单元测试、基准测试、示例测试等功能。本文详解其常用参数、调试技巧及性能测试命令,并提供实际项目中的应用示例与最佳实践。
|
3月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
737 23
|
2月前
|
人工智能 数据可视化 测试技术
UAT测试排程工具深度解析:让验收测试不再失控,项目稳稳上线
在系统交付节奏加快的背景下,“测试节奏混乱”已成为项目延期的主因之一。UAT测试排程工具应运而生,帮助团队结构化拆解任务、清晰分配责任、实时掌控进度,打通需求、测试、开发三方协作闭环,提升测试效率与质量。本文还盘点了2025年热门UAT工具,助力团队选型落地,告别靠表格和群聊推进测试的低效方式,实现有节奏、有章法的测试管理。
|
3月前
|
弹性计算 JavaScript Ubuntu
WebSocket协议相关的测试命令工具使用简介
本文介绍了针对WebSocket的测试工具wscat和websocat的基本使用方法,以及通过curl命令测试HTTP/HTTPS协议的方式。对于WebSocket,直接使用curl测试较为复杂,推荐使用wscat或websocat。文中详细说明了这两种工具的安装步骤、常用参数及连接示例,例如在ECS上开启8080端口监听并进行消息收发测试。此外,还提供了curl命令的手动设置头部信息以模拟WebSocket握手的示例,但指出curl仅能作为客户端测试工具,无法模拟服务器。
740 4
|
5月前
|
数据可视化 测试技术 API
JMeter、Apipost 与 Postman 的 API 测试对比:为什么 APIPost 是更聪明的选择
API测试如同筹备一场晚宴,选对工具至关重要。JMeter功能强大但上手难,适合专业用户;Postman简单易用,但在复杂场景和团队协作中表现有限;而Apipost则是一款智能高效的“厨房神器”。它性能测试轻松、结果清晰、学习门槛低,并且能一键集成CI/CD流程。对于追求效率与便捷的团队而言,Apipost无疑是更优选择,让API测试如同五星大厨烹饪般丝滑流畅。
|
5月前
|
SQL 安全 测试技术
2025接口测试全攻略:高并发、安全防护与六大工具实战指南
本文探讨高并发稳定性验证、安全防护实战及六大工具(Postman、RunnerGo、Apipost、JMeter、SoapUI、Fiddler)选型指南,助力构建未来接口测试体系。接口测试旨在验证数据传输、参数合法性、错误处理能力及性能安全性,其重要性体现在早期发现问题、保障系统稳定和支撑持续集成。常用方法包括功能、性能、安全性及兼容性测试,典型场景涵盖前后端分离开发、第三方服务集成与数据一致性检查。选择合适的工具需综合考虑需求与团队协作等因素。
678 24