jmeter及性能测试易错概念

1.线程!=并发

2.rps 每秒请求数

3.jmeter 同步阻塞方式

BIO  同步阻塞

NIO  异步阻塞

AIO   异步非阻塞

同步与异步同步与异步最大的区别就是执行方式和返回时机，同步指被调用方做完再返回，异步指被调用方先返回再执行、执行完将结果告诉调用方

阻塞与非阻塞阻塞指调用方发起一个请求，调用方一直等待被调用方返回结果，线程会被挂起无法进行其他任务非阻塞 就是调用方发起一个请求 不用一直等待被调用方返回结果，可以干其他事情
同步、异步、阻塞、非阻塞的区别同步、异步强调的是被调用方阻塞、非阻塞强调的是调用方

一般测试测接口不都去测接口的极限TPS，也就是拐点么？值都测出来了就可以了啊，再去增加所谓的QPS/RPS,如果服务端优化的够好，多余的请求都会进队列（NSQ）一类的东西进行排队，保证服务器不挂，代价就是响应时间越来越长而已，但是接口的处理能力就在那里了，一秒110个，你再怎么加，也只能还是110/s的处理能力，对于压力机来讲，最多也就1s能收到110个返回

这里有 线程数 TPS 响应时间 QPS 四个概念，
以例子中10个线程的数据来说，jemeter使用10个线程向业务发送请求，业务方平均处理平均响应时间为113毫秒，那么在第一个113毫秒（虽然是平均响应时间，这个地方简化理解，我当每个请求的处理都是113毫秒了）jemeter 10个线程收到第一轮结果后立马再向业务方发送请求。。。 如此 在1秒之内 jemeter的10个线程可以发送的请求数大概为88个，由于楼主固定了QPS，告诉jemeter你一秒内发40个就可以了，所以TPS只有40个。jemeter是利用线程循环使用来发送请求的，基于这点的话 QPS <= TPS。楼主期望jemeter 提供高于业务方处理能力的请求数，应该不限制QPS，而是提高线程数。
比如业务服务现在每秒只能处理100个请求，jemeter使用100个线程进行压测，平均响应时间应该就是1秒，现在楼主想压爆业务接口制造每秒200个请求，直接设置200个线程，结果就是有100个线程的请求能处理，另外100个请求业务方可能就是等待了，从结果看平均响应时间就会降低。
想压爆接口 其实目的是为了看接口能处理多大的请求，而不是已经知道处理的请求数再去做压测，有点本末倒置了。
这时候要看业务服务端能不能满足需求，不满足就要提高处理能力或者新增机器了。你把概念混乱了, 这就是个典型的接口压力测试. 你举例说明的那个75线程计算结果是实际的TPS, jemter发起的并发请求就是300,只是服务接口压力瓶颈在110左右,他把所有请求放在队列(猜测的)中处理,只要你的断言不设置超时就不会抛出异常.不是jemter上限只能发起110左右的request. 不谈响应时间的并发量是耍流氓
如果题主说的QPS是每秒请求数，TPS是每秒交互数。那就先说下我的看法：如果想得到有效的测试结果，那压力机的QPS是不可以大于服务器极限TPS的。举个例子，假如QPS比TPS大100，那压力机每秒都会多出100个在等待状态的连接对不对？。时间一久，会有多少在等待的连接？先不说服务器，压力机自己就要炸了。
so，这样的压力机只能提供不可控也不稳定的压力，如楼上所问，这样的压测结果意义何在呢？能提供稳定压力的压力机在不做特殊配置和丢包的情况下，每个线程都是在等待服务器响应结果后才会发下一个请求，这就意味着压力机的QPS就是要等于服务器的TPS的。
Jmeter和LR都是一样的机制，同步等待返回。所以如果服务器只能有200TPS，你加再多线程，都是一样的结果。如果你想要达到超过200的效果，你可以设置超时时间，也就是将发送请求之后等待响应这段等待时间缩短，到达超时时间就会报错，放弃等待而发送下一个请求。
兄弟你的脚本还不如现成的工具呢，一来 requests 库是同步的，二来 cpython 有 GIL，多线程有点鸡肋，虽然对这种主要耗时在I/O的场景影响不大，但以python的性能，最终还是达不到 jmeter、gatling、ab、wrk 的效果。至于jmeter是BIO的，这个我一直以为是搞性能的人的常识呢……如果有资源，更高压力可以通过多开实例或增加客户端机器达到，但未必会得到你想要的结果。在服务器或后台服务被压死之前，考虑一下请求根本到不了服务的情况：负载均衡/反代/网关/waf掐掉连接，netfilter哈希表用光弃掉IP包，请求在tcp监听队列、接收队列排队直到超时，连接数限制，文件描述符限制，然后spring cloud或tomcat各种配置限制……响应时间增加就是在排队，继续增加压力基本上只能看到计算出的响应时间越来越长，因为队列越来越长，后到的请求排了很久的队，最终看到的错误多半是连接超时或响应超时。其实不需要真的搞挂什么，只要业务给出这场景能接受的最大响应时间（或99%，99.9%之类）是多少，达到这个数的时候就是极限了。之后还有余量那是用来扛突发情况的，对用户来说不管挂不挂都是不可用了，在某些行业慢几毫秒可能已经出事了。
jmeter的请求方式是同步线程请求，基于这种请求方式，首先线程数不等于并发量，qps也只取决于服务器的处理速度。如果想要产生更高的压力的话，应该用异步线程，每秒发起多少次请求，然后就不管了，等下一秒再发起多少请求，这种才是真正的并发。
1.QPS指每秒查询数，通常用来记DB的性能的。 还是第1次看到QPS＝RPS的说法。我猜，jmeter QPS这个指标应该还是指db sql代码的性能测试吧。jmeter不熟，只能猜了。2.主流性能测试工具都是需要等回应的，如果事务返回正确，只有1个接口，一般RPS＝TPS，经常用LR的一般会看到这结果。3.RPS!=TPS，猜测一般是客户端发送没有出去，或者看看你单机处理的客户端流量，客户端也是需要做下监控的。4.从结果来看，如果压测机的流量正常，服务端的处理能力已经达到最大了。如果资源很少，你查一下一些参数设置，有可能是他们的影响。5.第4点排除后，如果你想让他报错，就继续加vuser吧，500一个请求也才4s，默认超时是60s。有时虽然没有报错，但不一定代码时间上可以接受。6.如果你想，压力机vuser N多，不等回应，然后分开计算RPS和TPS。 你可以尝试用python Gevent + scrapy，可以实现发和回的异步事件操作。
如果你的服务器性能只能处理110QPS的请求，那么即使JMeter在第一秒发起了200个请求，服务器只能处理110个，剩下的90个会在Web服务器的处理队列里面，连接会被挂起，JMeter也会一直等待这些请求响应，所以QPS才会稳定在110。而且现在的Web服务器这方面都处理得很好，基本不会出现因为并发量高使服务器宕机的情况。除非请求量特别大特别大，比如双11那种量级的。。。

1、理想情况：公式成立情况

TPS=并发数/平均响应时间
前提是服务器处理能力足够优秀，没有任何排队的情况下，网络耗时占响应时间极小的情况下，该公式成立。

2、实际情况：

TPS只跟服务器处理能力有关系，处理能力每秒多少，QPS或TPS就是多少(暂不考虑：因为排队导致资源紧张，导致服务处理能力下降)。

并发和tps、响应时间是关联关系，没有固定的公式、比例关系。更多的并发只能证明可能发出更多的请求，不能证明有更多的请求成功和服务器建联。