什么？界面可信度为啥要找 70 位测试去打分？这不是产品经理和 UI 要做的事情么

测最大可以承受多少并发很麻烦的。
不如用最大 tps&当前的并发&响应时间估算

感觉你的视角有问题，要测路口，关注的只是这个条路每秒能过几辆车。 每辆用时多久。
并发数只是用来保证这条路是饱和的，每个口子都有车在过。四个口子的话只要保持 4 的并发即可。
就算加到一万辆车一起过，除了在过口子的车，其他车都是无效的压力。因为对于四个口子的路口来说他们当前也只承受了 4 个并发而已，后面的车他们感知不到的。

只有这条路有 1W 个口子可以并排开过 1W 辆车的时候，并发才算是 1W

TPS 怎么算出来的是 4？

并发是 TPS* 平均响应时间，2*1.5 =3 啊。
并发 3 是意味着一直保持有三辆车在过闸口。

要是你说一共只有 8 量车，那并发量其实是根据时间在递减的。
你想啊，过了 1 秒后，还剩 4 量车，这时候并发还是 8 么？

TPS=并发数/平均响应时间是对的
TPS=总请求数/总请求耗时。
总请求数=并发量 * 总请求耗时/平均响应时间。

没办法，实在琢磨不出来，为啥我的反问句会被理解成疑问句

那线程在等什么呢？ 等迟钝了的服务器的返回对不对？ 压力没增加那为什么服务器迟钝了？

高线程等不等于高压力？44 楼的回帖你真的看懂了么？
增加线程没有增加压力的话，那服务器响应的延时会增加是因为什么呢？

1.不需要知道什么是 BIO，看过官方文档的就会认为更高的线程能造成更高的压力 （Number of Threads：Number of users to simulate.）
2.我根本没说线程==并发，这是你的误解。只是线程数和并发量一般都成正比，同样可以量化压力，方便你更好理解我才写括号里的。

再抬杠下次我可要收学费了哦。

我晕，他说的更高的压力明明指的是线程数（并发数）！ 这也能被理解成 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。