性能测试工具 Loadrunner 和 Jmeter 测试结果大 PK

周小丽 · May 31, 2017 · Last by 乄動聽縼葎ヤ replied at September 01, 2017 · 5118 hits

今天看了某人的一帖子https://testerhome.com/topics/8599, 论LR和Jmeter 测试大 PK,评论很精彩,用哪个工具进行压测本人觉得不重要,重要的是测试结果的准确性,以及数据监控的多样性。于是我分别用这2工具对同一登录功能进行压测,测试结果却都不一样,由于我用的是非破解版的Loadrunner,所以测试用户数只能是50个。
项目背景:服务器端是用PHP写的,mysql数据库,客户端是app。

测试一:1个用户陆续执行登录操作,迭代100次,运行完就结束

Loadrunner
测试配置如下:

设置为忽略think time,不存储log,取消download non-HTML resources

测试结果如下:

Jmeter
测试配置如下:

测试结果如下:

测试一结果对比:
登陆操作:1个用户迭代100次,运行完就结束
前提“LR忽略think time,不存储log,取消download non-HTML resources”
1、LR的平均事务响应时间为0.318s,而Jmeter的平均事务响应时间为318ms。
2、LR的TPS每秒事务数为3.03,而Jmeter的TPS平均为3.1。

测试二:50个用户并发执行登录操作(有集合点)

Loadrunner
测试配置如下:

集合点策略为:当50个用户都到达集合点后才执行,timeout为0

测试结果如下:

Jmeter
测试配置如下:

测试结果如下:

测试二结果对比:
1、LR的平均事务响应时间为3.453s,而Jmeter的平均事务响应时间为3298ms。
2、LR的TPS每秒事务数为9.701,而Jmeter的TPS是8.8。

共收到 23 条回复 时间 点赞

jmeter 是gui模式还是非gui模式运行的? 两种模式结果相差还是比较大哦

兄弟,你Jmeter线程组设置错了呀,循环次数不要写成1,勾选“永远”,不然只跑50次,虽然你写的是50个线程组。

1.第一种场景中,设置有2点问题
第一,Jmeter你的截图设置和你实际设置不一致,截图线程是50,Ramp up是100,实际运行应该是线程50,Ramp up是25,这样才是每秒并发2个,你可以看Jmeter中的结果图24秒就结束啦。

第二,为什么TPS不一致,那是因为你2种工具设置不一致,造成较大误差,LR中,启动好50个VU后,还要保持50个VU运行5分钟才结束且每个VU启动后还会持续运行;而Jmeter,启动完50个线程就结束了且每个线程运行一次后就结束,所以最后就发送了50个请求,你可以看看LR的总共请求数肯定远远大于Jmeter。这点你可以使用jp@gc - Stepping Thread Group的这个线程组

然后说说你看到的响应时间,Jmeter是直接post的请求,只要服务器返回响应就结束,而LR是真实的填入用户信息,在post,之后回来还会解析成页面,这个LR肯定耗时,但是压测页面方面,LR更接近真实,Jmeter更适合后端服务和数据库的方面的压测

2.第二个场景中,Jmeter倒是设置的是50了,RampUp是100了,但是你线程运行次数还是1,而且设置了集合点,那就是每2秒启动一个线程,攒够50个线程,走一波,结束。。。jp@gc - Active Threads Over Time这个应该只是记录发送请求时的状态,而中间线程启动等待50的过程,不算。从你设置和Jmeter的结果来看,真正的压测,就是50个线程一波这个,没看出来TPS,25在哪里。

牛,第一种场景中的jmeter线程组的配置确实是我上传错了图片,Ramp up应该是25

莫离 回复

jmeter 是gui模式,那我们测试是LR还是Jmeter测试出的更贴近真实情况呢?

DeX 回复

我本意就是让50个线程,各跑一次就行了,就跟LR一样也是设置的迭代为1次。我想知道的是2种工具同样的设置,到底哪个更为接近真实情况

【LR中,启动好50个VU后,还要保持50个VU运行5分钟才结束且每个VU启动后还会持续运行】,我想问下持续运行的5分钟内,VU还会反复发登陆的请求吗? 我理解的是每个VU只发一次登陆请求,然后持续运行的5分钟内,只是VU在那呆着,什么也不做,5分钟后VU退出

为你这种动手能力点赞

周小丽 回复

你第一个中LR那种设置方式是~ 事物完成后继续下次事物直到5min结束为止~ 而jmeter那种设置对应的是lr的only once那种~ jmeter官网在能写的地方都写了gui模式仅用于code和调试。
哪个更贴合实际情况的话,我觉得只要负载发生器没瓶颈,没多大差别。

好比,呼的刮了一阵风,说明不了今天风力几级一样。。。

周小丽 #12 · June 01, 2017 作者
果冻 回复

能说具体一点不

周小丽 回复

你用jmeter持续3分钟,跟你现在测出来的结果肯定大不一样...

周小丽 #14 · June 01, 2017 作者

嗨,我最后用jp@gc - Stepping Thread Group这个线程组

这和LR中的control是一样的

可是吞吐量怎么差距那么大啊?LR的TPS每秒事务数为4.256,而Jmeter的TPS一直都是49.7,相差近12倍了。

关于响应时间,要看看脚本了,因为网页存在各种元素,有可能是异步加载的,这个在LR中也被算进去的。就以当前TesterHome这个页面来说,可以打开F12,你会发现,除了一个最基本的请求本网页,还有一大堆图片,js进行了异步加载,这个在LR中是耗时间的。
所以你要对比2边的脚本来看是否只是包含了最基本的请求。

TPS:Jmeter是当前时间的TPS,也就是实时当前秒的TPS。TPS这个要弄清楚,建议2边都一个线程/vu,运行1分钟,看看总事务是否一致,如果不一致,你可以看看各自工具中,响应时间,TPS,总事务是否能对上

Jmeter的线程,如果你设置好永远,那就是不断的发送请求,当这个请求发出,接收到之后,立马进行下一次请求。所以抛开脚本问题,Jmeter是不会错的,因为用我们这边用的太多了,都要吐了
LR就是刚入行的时候,用过,不精不敢说了,现在我们部门到整个公司都是在用开源工具了。

后面是废话
还有就是如果你是针对的网站,网页进行压测,还是用LR吧,有脚本能力可以考虑gatling、nGrinder(这个可以在阿里的PTS上录制生成脚本。。。),如果是后台接口,服务,数据库方面的,感觉jmeter比LR方便。

现在做了好多性能测试,感觉工具不是第一位的,重要的是前期分析压测目标,架构,这个好了,才是来调整脚本达到目的,最后就是分析了

周小丽 #16 · June 02, 2017 作者

我明白了我之前的LR的脚本中除了login登陆外,还有登陆中的各种借口请求,如下图

于是我再jmeter中也添加了这些请求,如下图

但问题是业务部要求用户登录行为(要求成功进入系统首页)的TPS为20,那我看这登陆行为的TPS应该是上图中的13.7呢 还是231?,另外这一登陆行为的用户响应时间是要将这所有接口的响应时间加起来吗?,如下图

先说你的问题,要看整个登录过程的响应时间和TPS,这个在jmeter中的线程组下面,设置事务控制器,把所有的请求放到事务下。然后勾选Generate parent sample,是不是和LR一样了。
这样就构成了一个登录的事务。我看到你调用的都是接口,没有图片?没有js?

在你考虑页面的时候,也要站在用户的角度,比如,淘宝,一个网页那么多东西,不会一下子加载好了,同时呈现给用户,而是加载好核心内容,比如左边菜单,然后广告,用户信息,推荐,图片,在进行异步请求,这样呈现出来。那么我们是不是只要抗住核心页面的东西就行了?保证核心页面的速度,一样可以给用户很好的体验。那是不是你压测你事务的时候,就可以去掉一些接口

然后说说提到的业务要求TPS,20,这个你要仔细分析想一下,到底是RPS还是TPS?
如果是RPS,那么就是一秒钟有20个人来并发,但并不是要求1秒都完成,这个时候就要看看每个事务完成需要多少时间,同时询问业务人员,能容忍一个登录花费多少时间?我可能并发了20个登录请求,但每个登录事务2秒结束,这个是不是符合业务的要求?

如果是TPS,要求一秒能处理20个登录请求,那么要看,你是并发了多少个用户才打到20个TPS的?在达到20个TPS的时候每个事务花费多少秒,即用户的等待时间?

压测页面,你们用loadrunner吗?

Michael_Wang 回复

不用的,有2个方面,一个是我们Online的占比越来越低,大部分来源都是app和H5,另外一部分就是外部分销了,瓶颈不在web而是都集中在后端:商品服务和订单系统

第二:LoadRunner要收费,所以使用开源工具,虽然数据采集不如LR,但是够用,因为我们服务器本身就有很多监控,结合起来看不比LR差。当然压测页面我们还是不会使用jmeter,而是其他开源工具。

这个是我们的情况,压测时,还是根据自己公司的情况来选择。

周小丽 #21 · June 05, 2017 作者

问下jmeter有类似于LR的页面分解功能吗?如 firstbuffer,received的耗时

22Floor has been deleted
周小丽 回复

jmeter没有,前面也说过,我们系统有各种埋点,页面的domready,运营商耗时,接口服务端响应时间,每一个慢请求的追踪。这个比起测试工具收集的更准确。
LR中的各种指标没有深究过,只是不明白,它只是从客户端来统计,怎么区分是服务端处理有问题,还是网络有问题。

jmeter大并发的时候jvm经常被爆,有怎么处理么?

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up