Loadrunner 和 Jmeter 测试结果大 PK

乐哈哈yoyo

用哪个工具进行压测本人觉得不重要，重要的是测试结果的准确性，以及数据监控的多样性。于是我分别用这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

悠悠小仙仙

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 是gui模式还是非gui模式运行的? 两种模式结果相差还是比较大哦

草帽路飞UU

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