贴的这个是 MacacaClient 文件里面的代码。

这个调试的时候，看过返回是 int。

请问你这个 ip 是 ping 命令 ping 出来的吗

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

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

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

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

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

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

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

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

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

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

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

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

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

哈哈哈，我也是从事互联网的，以我的工作环境来说，支持@seveniruby说的，我们工作确实遇到了，对于大型互联网来说，LR 确实使用太少了，至少我们公司就没听说，一般都是 Jmeter，ngrinder，还基于 ngrinder，进行二次开发，配置可扩容的压测集群，模拟生产流量等等，各种报告，也可以收集起来，进行定制展示。
但 LR 各种书籍很多，入门和上手相对容易，工具较丰富。

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 在哪里。