针对性能测试工具Gatling与Jmeter的比较及看法-阿里云开发者社区

开发者社区> smooth00> 正文

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

简介: 对于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或其他调度工具同时触发调度测试)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
《全栈性能测试修炼宝典 JMeter实战》—第1章 1.4节不仅仅是性能测试
随着国内软件质量体系的健全,企业逐渐意识到软件测试质量不单单是满足功能流程顺畅就行,测试效率和用人成本的降低也是趋势,更要为软件的稳定和易用性等质量保障来提高产品黏性留住用户。
1627 0
区块链数据分析必备工具BlockETL
BlockETL软件包用于比特币区块链数据分析中的数据抽取/转换/加载(ETL),可以从原始的比特币区块文件中抽取区块与交易数据并加载入通用SQL数据库,以便于后续的数据分析处理,非常适合区块链数据分析相关的毕业设计或课题研究项目。
1157 0
分布式实时分析数据库citus数据查询性能简单对比
分布式实时分析数据库citus数据查询性能简单对比 如果单纯看实时数据插入的速度,并不能体现citus的价值,还要看聚合查询的性能。下面将集群的查询性能和单机做个简单的对比。
2187 0
新功能:日志服务命令行工具ETL发布!
日志服务命令行工具ETL发布,解决数据采集、分析查询、投递归档、外部整合过程中的数据规整痛点,提供实时、可靠、可扩展、可管理的运行模式支持,以及全面简单的ETL规则,并支持丰富的扩展支持。
3026 0
《全栈性能测试修炼宝典 JMeter实战》—第1章 1.3节软件测试发展路线
测试的可塑性很强,还有很多其他方向可以发展,同样能够创造更高的价值.
1236 0
《全栈性能测试修炼宝典 JMeter实战》—第1章 1.2节软件测试痛处
就目前国内情况来看,大多数的测试人员并没有开发和运维的技术功底,选择测试这个行业仅仅是因为高薪和入门门槛低。近年来互联网和P2P的神话,快速抬高了测试平均工资,却没能快速提高这个行业的技术水平。
862 0
《全栈性能测试修炼宝典 JMeter实战》—第1章 1.1节为什么选择软件测试
市场上有各式各样的IT培训,其中门槛低易上手的就是软件测试。就业的学员通常都以功能手工测试为切入点,掌握一些基本测试理论,学会设计测试用例,能够操作缺陷管理工具,熟悉一些业务就可以开始测试工作了。
1592 0
+关注
smooth00
从事过软件开发、软件测试、技术管理工作;目前专职于性能测试,擅长Jmeter、Loadrunner、Selenium、Jenkins等工具的应用和Docker及自动化构建,在性能测试、性能监控、性能分析方面有较多的实战经验。https://smooth.blog.csdn.net
54
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载