今天看了某人的一帖子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。
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 在哪里。
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 和调试。
哪个更贴合实际情况的话，我觉得只要负载发生器没瓶颈，没多大差别。
好比，呼的刮了一阵风，说明不了今天风力几级一样。。。
逝去的青春
回复
嗨，我最后用 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 方便。
现在做了好多性能测试，感觉工具不是第一位的，重要的是前期分析压测目标，架构，这个好了，才是来调整脚本达到目的，最后就是分析了
逝去的青春
回复
我明白了我之前的 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 的时候每个事务花费多少秒，即用户的等待时间？
Michael_Wang
回复
不用的，有 2 个方面，一个是我们 Online 的占比越来越低，大部分来源都是 app 和 H5，另外一部分就是外部分销了，瓶颈不在 web 而是都集中在后端：商品服务和订单系统
第二：LoadRunner 要收费，所以使用开源工具，虽然数据采集不如 LR，但是够用，因为我们服务器本身就有很多监控，结合起来看不比 LR 差。当然压测页面我们还是不会使用 jmeter，而是其他开源工具。
这个是我们的情况，压测时，还是根据自己公司的情况来选择。
周小丽
回复
jmeter 没有，前面也说过，我们系统有各种埋点，页面的 domready，运营商耗时，接口服务端响应时间，每一个慢请求的追踪。这个比起测试工具收集的更准确。
LR 中的各种指标没有深究过，只是不明白，它只是从客户端来统计，怎么区分是服务端处理有问题，还是网络有问题。
jmeter 大并发的时候 jvm 经常被爆，有怎么处理么？