我晕，他说的更高的压力明明指的是线程数（并发数）！ 这也能被理解成 QPS……

我也不期待能说服你什么了，大家各忙各的吧。

1.44 楼哪句说了 jmeter 多实例和分布式可以做到 rps>tps？
2.RPS>TPS 压力机没炸只有三种可能：要么你测试脚本没做到 RPS 大于 TPS，要么压测时间还不够长，要么服务器先炸了。
3.一般情况下， jmeter 增加线程数测的 TPS 不变的时候，对应的 tps 就是服务器能承受的最大 rps，也就是 120。
另外，欢迎找个公网接口贴测试结果来反驳我的结论

首先你压测出 120 是就是服务器能承受的最大 RPS，再多哪怕一点点，持续下去拐点都会出现，但要等多久就说不好了。（为什么，请看吓我楼上的回复）
你可以用 AIO 或者 NIO 的方式模拟用 120+ 的 rps 去试试，但是用异步请求的客户端，自身的稳定性和压测数据的统计实现起来都是个问题。就算出现拐点了客户端也不知道。

这里 jmeter 作为 BIO 不存在这些问题，通过实时增加并发数就可以测出最大 TPS 和拐点，这也是为什么主流的压测机都是 BIO 的原因

如果题主说的 QPS 是每秒请求数，TPS 是每秒交互数。

那就先说下我的看法：如果想得到有效的测试结果，那压力机的 QPS 是不可以大于服务器极限 TPS 的。

举个例子，假如 QPS 比 TPS 大 100，那压力机每秒都会多出 100 个在等待状态的连接对不对？。时间一久，会有多少在等待的连接？先不说服务器，压力机自己就要炸了。
so，这样的压力机只能提供不可控也不稳定的压力，如楼上所问，这样的压测结果意义何在呢？

能提供稳定压力的压力机在不做特殊配置和丢包的情况下，每个线程都是在等待服务器响应结果后才会发下一个请求，这就意味着压力机的 QPS 就是要等于服务器的 TPS 的。

一些评论中的说法，我觉得还是有误导性的。 希望大家可以辩证的看。

BlazeMeter 做过一个比较，个人觉得还算中肯 :
url: https://www.blazemeter.com/blog/jmeter-vs-locust-which-one-should-you-choose

相对于 jmeter，locust 确实有一些自己的优势，比如脚本更易于维护，且内存占用相对小等。但是目前综合实力和生态确实不如 jmeter。
楼主从源码分析推断出的观点还是挺有说服力的，希望同学在评论时向楼主学习。尽量客观不要凭感觉进行臆测。

压测脚本本身的耗时也会算进响应时间的。 之前遇到过压测机承担不了这么大并发。就会让响应时间变高。

这是谷歌的内部用例管理平台么

让我选我会首选 node，容易开发平台化的测试工具，方便统计测试数据和维护。
其次 python，数据处理分析上有优势，但是 python23 版本相互不兼容，这点让人很不爽
最后不行就 JAVA，因为开发选型都是 java，不得不用 java 测接口

羡慕楼主可以有机会使用这么多的语言。
其中对 nodejs 的评价和定位我觉得我觉得有失偏颇。
对于实时性要求比较强的终端应用，nodejs 是很好的选择。 比如 appium 和 STF。